unable to establish connections after upgrading

[nightfall]

Hello, i've just upgraded my server/firewall to 4.6 from 4.4.
After rebooting, i could not connect to the internet from the server itself, even though all the other client in the network actually can. The server is also reachable from the Internet (i can connect to sshd, httpd and so on). I thought at first that it was a dns issue, but it's not. When I try for example to connect to google from lynx, it does resolve properly, but it gets stuck on "Making http connection to..".
Routing tables seem ok, and also setting "pass in all/pass out all" on pf makes no difference.

here are some outputs from tcpdump when i try to connect to google

[ ~ ]# tcpdump -t -vn -i fxp0 host google.it
tcpdump: listening on fxp0, link-type EN10MB
192.168.1.69.16439 > 209.85.227.99.80: S [tcp sum ok] 3357743172:3357743172(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1972349919 0> (DF) (ttl 64, id 28053, len 64)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021253181 1972349919,nop,wscale 6> (ttl 52, id 48106, len 60)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021253524 1972349919,nop,wscale 6> (ttl 52, id 48107, len 60)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021254125 1972349919,nop,wscale 6> (ttl 52, id 48108, len 60)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021255325 1972349919,nop,wscale 6> (ttl 52, id 48109, len 60)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021257725 1972349919,nop,wscale 6> (ttl 52, id 48110, len 60)
192.168.1.69.16439 > 209.85.227.99.80: S [tcp sum ok] 3357743172:3357743172(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1972349931 0> (DF) (ttl 64, id 498, len 64)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021259181 1972349919,nop,wscale 6> (ttl 52, id 48111, len 60)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021262575 1972349919,nop,wscale 6> (ttl 52, id 48112, len 60)
192.168.1.69.16439 > 209.85.227.99.80: S [tcp sum ok] 3357743172:3357743172(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1972349955 0> (DF) (ttl 64, id 38020, len 64)
209.85.227.99.80 > 192.168.1.69.16439: S [tcp sum ok] 3266835413:3266835413(0) ack 3357743173 win 5672 <mss 1430,sackOK,timestamp 2021271181 1972349919,nop,wscale 6> (ttl 52, id 48113, len 60)

Thanks in advance!

[jggimi]

I'm going to take a wild guess that you upgraded without using Upgrade FAQs, and that you use PF.

From the 4.5 -> 4.6 upgrade guide:

...If you reboot your system without a usable pf.conf file in place, your pf rules will not be loaded, and you will end up using the default rule set, which will block all traffic EXCEPT for ssh over the standard port 22. This means that if you do not fix your pf.conf rules before rebooting, you may be greeted by a box that does not even respond to pings...

[nightfall]

hi jggimi, thanks for the answer.
it's not a pf problem, as i've tried also with the pass in all /pass out all, and the system IS reachable from the outside.
the problem is that it seems that it's impossible for any application to connect to the outside world from the server itself. as showed by tcpdump, it tries to connect, and it receives datas too, but it's not able to completely establish the connection. it's kinda weird..

[jggimi]

Can you connect to other systems in your 192.168.1 network? Yet still not connect elsewhere?

If so, then your problem -is- routing.

[nightfall]

i'm feeling really stupid, but still i can't find the reason. it must be the routing for sure, but damn it seems all correct.
here's route's output:

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 192.168.1.254 UGS 6 215 - 8 fxp0
127/8 127.0.0.1 UGRS 0 0 33200 8 lo0
127.0.0.1 127.0.0.1 UH 0 0 33200 4 lo0
192.168.1/24 link#2 UC 4 0 - 4 fxp0
192.168.1.2 00:12:79:8f:ca:b0 UHLc 0 47 - 4 fxp0
192.168.1.105 00:24:d6:46:42:72 UHLc 0 0 - 4 fxp0
192.168.1.198 00:23:6c:8d:a1:4f UHLc 3 124 - 4 fxp0
192.168.1.254 00:17:c2:92:b7:0c UHLc 1 0 - 4 fxp0
224/4 127.0.0.1 URS 0 0 33200 8 lo0

[ ~ ]# cat /etc/mygate
192.168.1.254

[ ~ ]# cat /etc/hostname.fxp0
inet 192.168.1.69 255.255.255.0 NONE

[jggimi]

inet 192.168.1.69 255.255.255.0 NONE

Just another guess, bad broadcast address, perhaps?

You post info in dribs and drabs. So since I haven't seen your ifconfig(8) output, I would look there.

Use [code][/code], rather than [quote][/quote] if you want to preserve readability.

[nightfall]

Sorry for being messy! i did not know the differences between the two tags.
i've been using the same machine (well, the same hard disk on various machines to be honest ) since 2.9, and these network settings in particular for at least 2 years... and they never gave me any problem. damn!
so here again the infos with the right tagging

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:02:a5:dd:5b:82
        priority: 0
        groups: egress
        media: Ethernet autoselect (10baseT half-duplex)
        status: active
        inet6 fe80::202:a5ff:fedd:5b82%fxp0 prefixlen 64 scopeid 0x2
        inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255

and the routing table again

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            192.168.1.254      UGS        3     9539     -     8 fxp0
127/8              127.0.0.1          UGRS       0        0 33200     8 lo0
127.0.0.1          127.0.0.1          UH         0        0 33200     4 lo0
192.168.1/24       link#2             UC         4        0     -     4 fxp0
192.168.1.2        00:12:79:8f:ca:b0  UHLc       0     1725     -     4 fxp0
192.168.1.105      00:24:d6:46:42:72  UHLc       0        6     -     4 fxp0
192.168.1.198      00:23:6c:8d:a1:4f  UHLc       2      286     -     4 fxp0
192.168.1.254      00:17:c2:92:b7:0c  UHLc       1        0     -     4 fxp0
224/4              127.0.0.1          URS        0        0 33200     8 lo0