No IPsec lan traffic after 2.1 upgrade, requires extra lan rule cuz gw group?
So I have two boxes.
One in a data center and it is running 2.1 12/28 snapshot.
I had another at office running 2.0.2. (This one has Daul WAN & Dual LAN)
WAN1 -> LAN1
WAN2 -> LAN2
Two gateway groups setup, one has WAN1 primary and WAN2 secondary and other the other way.
LAN1 uses the first group and LAN2 the second, so if the WAN1 fails LAN1 will failover to use WAN2.
Everything has been working fine. IPsec tunnel between the two working great. I have been using groups to handle failover for WAN connection and on the 2.0.2 box had the LAN1 tab set so all outbound traffic is allowed but the gateway used was WAN_failover1 (name of one of the groups).
Today I figure meh, why not, so I upgrade the 2.0.2 box using GUI to 2.1 snapshot dated today.
Now I seem to have a problem. The IPsec connects but routing seems wrong. LAN hosts can't ping anything on remote network but pfsense can.
So I tried search and found this http://forum.pfsense.org/index.php/topic,28506.0.html
For giggles I changed my LAN1 from using the gateway group to the default one and the traffic now passes. Problem is this means failover won't function.
I also don't get it because that above link is kind of old and I had it working on 2.0.2 as stated in begining of my post and in fact have since ver 1.2 even and just now have issues on 2.1?
I know it's a routing issue because when I use my failover group for gateway it tries to route the remote ipsec traffic out of the wan1, but when I set to default vs my group it routes correct. (found running tracert on windows.)
Suggestions? Did something change between 2.0.2 and 2.1 on how this works? How do I proceed? The datacenter is fine because only 1 wan but I am lost.
Has this just been working incorrectly all this time?
The dirty method is for me create another LAN rule for traffic going to ipsec subnet to use default, but that seems silly now? why would I need it now vs never before, should the original LAN rules that says any any cover it? Using a gateway group I would still expect the thing to look at its routing tables no?
That's the expected behavior if the policy route isn't negated, we negate that automatically though.
check your /tmp/rules.debug for something like the following:
pass in quick on $LAN inet proto tcp from any to <negate_networks>flags S/SA keep state label "NEGATE_ROUTE: Negate policy routing for destination"</negate_networks>
that rule will be right above your user-defined pass rule. Also look at the negate_networks table towards the top of the file. It should have your remote VPN subnet. On a system with a very recent snapshot, that all works as it should be.
The upgrade must have not done something right because I see this:
pass in quick on $LAN inet from 10.10.100.0/24 to 172.16.1.0/24 keep state label "USER_RULE: IPsec Traffic" pass in quick on $LAN inet from 10.10.100.50 to <negate_networks>keep state label "NEGATE_ROUTE: Negate policy routing for destination" pass in quick on $LAN $GWBH_Primary inet from 10.10.100.50 to any keep state label "USER_RULE: BH Gateway for testing" block in quick on $LAN from 10.10.100.0/24 to 10.10.200.1/26 label "USER_RULE" pass in quick on $LAN from $Admin_Phone_Lan_Crossover to 10.10.200.1/26 keep state label "USER_RULE: Admins to Phone Subnet" pass in quick on $LAN from 10.10.100.0/24 to <negate_networks>keep state label "NEGATE_ROUTE: Negate policy routing for destination" pass in quick on $LAN $GWATT_Primary from 10.10.100.0/24 to any keep state label "USER_RULE: Default allow LAN to any rule"</negate_networks></negate_networks>
I removed an old rule```
block in quick on $LAN from 10.10.100.0/24 to 10.10.200.1/26 label "USER_RULE"
The other rule showing above that says BH Gateway for testing was actually disabled so dunno why it showed but after the removal of the one old rule i now see this:
pass in quick on $LAN inet from 10.10.100.0/24 to 172.16.1.0/24 keep state label "USER_RULE: IPsec Traffic"
pass in quick on $LAN from $Admin_Phone_Lan_Crossover to 10.10.200.1/26 keep state label "USER_RULE: Admins to Phone Subnet"
pass in quick on $LAN from 10.10.100.0/24 to <negate_networks>keep state label "NEGATE_ROUTE: Negate policy routing for destination"
pass in quick on $LAN $GWATT_Primary from 10.10.100.0/24 to any keep state label "USER_RULE: Default allow LAN to any rule"</negate_networks>
So right now I only have three active rules, shown in the bottom one however if I disable that top one I made my IPsec traffic dies and I didn't use to need that. What I don't get is why the top one and this one are showing different and all I did was delete the one block rule that was old from something else. Anyway not sure if this helps any. From what I read on http://doc.pfsense.org/index.php/Multi-WAN_2.0 it looks like I do require the rule but I still don't get why in the past I didn't and now I did esp if you're saying I really shouldn't because that should be handled. This was a clean 2.0.1 install that was updated to 2.0.2 on release day and today updated to that snapshot. On the 2.0.x and even older version I had same confgs always and never need that extra lan rule. A clean install would be kind of a pain at the moment as I have many rules on the WAN setup so no easy way for me to test if that would fix it. Thx in advance for any help.
Just bumping again as this still doesn't work without my manual rule even on todays snap.
Anyone else able to confirm this or thoughts?
same here ….
I can confirm exactly the same problem occurs in 2.1 snapshots since December 2012 (earlier builds were OK, there was no config change at all, it just stopped working some day after upgrade). Today I finally found a problem. It seems this bug occurs only in in dual WAN configuration when you define any additional rules at LAN side (in my case two firewall rules on LAN that send traffic from selected IPs through WAN1 or WAN2) all IPsec routes are ignored and no traffic is send to IPsec tunnel! Seems that 2.0.2 has exactly the same bug! http://forum.pfsense.org/index.php/topic,57274.msg308710.html#msg308710
This thread is referencing 2.1 not 2.0.2, 2.0.2 had no changes related to this. This is how things are supposed to work without the negation work around we put in place to prevent you from foot shooting. 2.1 has changed some in this regard and that needs to be re-evaluated.