'Limiter' rules bug when upgrading to latest 2.1-BETA0 snap
TEMPORARY SOLUTION: DISABLE ANY RULES USING LIMITERS (h/t phil.davis) or don't upgrade to latest 2.1-BETA0 snaps until the issue is resolved
This is a very quick heads up that since upgrading to latest beta snap, I seem to have connectivity problems.
FreeBSD fw.localdomain 8.3-RELEASE-p4 FreeBSD 8.3-RELEASE-p4 #1: Fri Oct 12 10:10:48 EDT 2012 root@snapshots-8_3-i386.builders.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386
config.xml is basically the same I've been running for the past year.
I haven't yet had the time to troubleshoot the issue, but it seems that systems behind pfsense's NAT are unable to reach IPs in subnets that aren't directly connected (they can reach IPs in WAN subnet).
E.g. outbound ssh from hosts in LANnet (outbound NAT is set to automatic) won't work, except to hosts in WANnet
packets aren't blocked
tcpdump on pflog0 doesn't show anything blocked
attempt to ssh to remote host fails:
tcpdump -i em1 (LAN if) port 22 shows the ssh packet coming in, but no traffic on em0 (WAN if)
attempt to ssh to a host in WANnet subnet works
tcpdump prints the relevant traffic both on em1 and em0
the pfsense box itself connects fine to anyone (ssh, telnet to port 80 etc)
checking states with pfctl -ss
all tcp xxx.yyy.z.4:22 <- 192.168.100.12:3725 ESTABLISHED:ESTABLISHED
all tcp 192.168.100.12:3725 -> xxx.yyy.z.201:26443 -> xxx.yyy.z.4:22 ESTABLISHED:ESTABLISHED
all tcp xxx.yyy.z.3:22 <- 192.168.100.12:3768 ESTABLISHED:ESTABLISHED
all tcp 192.168.100.12:3768 -> xxx.yyy.z.201:31952 -> xxx.yyy.z.3:22 ESTABLISHED:ESTABLISHED
all tcp aa.bb.40.155:22 <- 192.168.100.12:3841 CLOSED:SYN_SENT
xxx.yyy.z.0/24 is WANnet
aa.bb.40.155 any other remote host
If you have any rules with limiters, it is broken. I have put 1 pull request for a small interface bug, which has been sitting there for a day now without any action or comment on it. But it really needs someone (the originator of the commit that broke it?) to urgently fix this or revert it.
Disable any rules with limiters and routing/filtering should come back to life.
Notice to all: If you use limiters then DO NOT update to current snapshot until this problem is fixed.
phil.davis thanks, it was indeed due to 'Limiters'
(note: in my setup the "WAN net" was excluded from the Limiter rule which had a Destination ! xxx.yyy.z.0/24 )
After disabling that single Limiter rule, everything seems to be back to normal.
I can also confirm the limiter bug in the snap, disabling the limiter clears the issue.