Update pfsense 2.0.1 stable to 2.1 problem with routes
-
It seems very strange to me that you have a private subnet somewhere upstream of your public WAN IP.
You need to look at the pfSense routing table and see if it has somehow acquired a route to 192.168.. on the WAN. Perhaps via some new routing protocol introduced in 2.1.
Normally if you had specified a gateway in the firewall rule, and that rule is actually catching the traffic, then it can only use that gateway. However there is a background rule that will by-pass that for local networks the 'negate rule'. You can turn it off in System: Advanced: Firewall/NAT. That also existed in 2.0.3 but perhaps it didn't recognise it as local there.
In 2.0.3 do you need to have a firewall rule specifying a gateway?
Specifying a gateway on the same interface that the traffic arrives is the sort of thing that can fail to work. See NAT reflection for example.
Steve
-
I spent alone with the IP 192.168.1.20, it happens with all routes. A little weird right? Indeed, for fanjar this topic I say I've tried to add the same routes to pfsense 2.1 BETA and I have worked flawlessly. Pfsense 2.1 if stable has a bug or if, or add something new to fuck routes because it does not work any of the 4 that I have on pfsense 2.1 stable. There is a bit weird that I work perfectly in pfsense routes 2.0.1 stable and 2.1 BETA!
Thanks for everything.
-
Same problem her. In 2.0.3 routes work fine, in 2.1 do not!
Test upgrading in place and fresh install, both not work. -
The same sort of static routes to an internal gateway?
Steve
-
Yep! two Pfsense with Wan in same network.
-
Can you specify the routes and under what conditions they don't work? For example maykel535 was able to use the route from the pfSense box itself but not from a client in the same subnet as the gateway.
Steve
-
do not compliqueis more, I can not lose more time with this because in pfsense 2.1 BETA works. Something as simple as a route, I can not lose more time. There is a bug and I just want to help you solve … A shame since pfsense 2.1 stable comes with a amount of improvements as MultiWAN dynamic dns and a bunch of bug fixes.
The real problem is that instead routes of enrutarte to the host that is, it takes you out to the wan and not because there is anything wrong, but simply routed bad this version of pfsense 2.1
We will have to wait ...
-
any officiale update or replay to this problem?
Upgrading to 2.1 in multi WAN-LAN configuration is a hell! -
I too had some routing issues from 2.03 -> 2.1. I think 2.0.3 was more forgiving with routes than 2.1. And interestingly enough, I too am running a multi-WAN.
In my configuration I have two LANs and two WANs. I want each LAN to go out a different WAN, so I created a rule with each gateway in it.
When this is set up in 2.0.3, LAN to LAN2 communication will occur without a specific rule to route traffic between them. However, I had to specifically create a rule in each LAN to route traffic between them or else it would not happen. I assume this is due to creating a rule specifying which gateway each LAN needs to use. It was pretty frustrating for a few week since the LAN serves resources up to LAN2 and vice versa.
I've attached screen shots of my new rules. But as I mentioned before, an upgrade from 2.0.3, which was working flawlessly, to 2.1 required me to troubleshoot and create new explicit rules to route traffic between my two LANs.
So for folks experiencing issues, I would recommend that you sit down and think about rewriting your rules and validating them. I had to do hours of testing to ensure that my new rules worked and didn't break anything else.
 -
Using OpenVPN tunnel with ovpns1, and created a route does not accept ipv6 automatically switch to ipv4 and remove.
Was not done the update version 2.0.3 is rather a new installation
-
Hi Tim,
I just added the crossing rules from LAN1 to LAN2 and viceversa, and I put them before the rule that send the traffic to a specific routing group (otherwise the intranet traffic goes out to the gateway!?!?!) but I still have problem… I will try to reset the configuration and restart, but I have 40 rules and nat with 6 interfaces, I never had problems in upgrading before :-(Alessandro
-
The issue I was experiencing was limited to the two LANs communicating. I have many rules on my WANs, but my LANs are rather simple (by design). Have you done any troubleshooting to know specifically where the issue is occurring and which routes are affected?
I always start with a ping and traceroute, and then check the firewall logs. I can usually determine rather quickly why things aren't getting from point A to point B using those three tools. If you need assistance interpreting those things, just post the data here. Another suggestion; I usually time my testing on 5-minute intervals so I can match up different logs with one another. Sometimes if you test, make a change, and test again, you can miss things in the logs.
-
The behavior of policy based routing, which is what we're dealing with here, changed between 1.2.X and 2.0.X. At that time automatic 'negate' rules were added behind the scenes that allowed traffic to negate a policy based rule when the destination is a local subnet. I was burnt by that change because I had rule sets that had previously not allowed traffic between local subnets that now suddenly did. Worse, I didn't realise anything had changed for some months. That'll teach me to read the release notes properly. ::) Anyway after some requests a check box to disable the negate rules was added in System: Advanced: Networking: I always have it unchecked, I don't want the negate rules catching me out again. I wonder if the behaviour changed again in 2.1, it seems to fit the symptoms.
Steve
-
This thread saved me over the weekend when I did my upgrade :)
Also worth noting, you need some new rules if you're using NAT reflection and policy based routing. I had to add rules for LAN->LAN, LAN2->LAN2, VLAN1->VLAN1 etc for NAT reflection to work.
EDIT - Oops, post corrected to say NAT reflection, not 1:1 NAT. I had a 1:1 NAT config page open at the time :)
-
do not compliqueis more, I can not lose more time with this because in pfsense 2.1 BETA works. Something as simple as a route, I can not lose more time. There is a bug and I just want to help you solve … A shame since pfsense 2.1 stable comes with a amount of improvements as MultiWAN dynamic dns and a bunch of bug fixes.
The real problem is that instead routes of enrutarte to the host that is, it takes you out to the wan and not because there is anything wrong, but simply routed bad this version of pfsense 2.1
We will have to wait ...
Just to say I can confirm a route problem on 2.1-RELASE.
For maykel535 and admins: On 2.1-RC1 (15aug snapshot) I got no problem, hence "bug had been introduced between 15 august and 16 sept (2.1 release date))
In my case I can not route one OpenVPN LAN. See http://forum.pfsense.org/index.php/topic,68031.0.html
Maybe jimp can help us….Thanks
-
I can also confirm that upgrading from 2.0.3 to 2.1 release has a routing issue. The LAN interface appears to route traffic fine but other interfaces only route to the default gateway. I've confirmed that the router ignores its static routes and locally connected subnets (for interfaces other than LAN). It just sends everything to the default gateway. All the interfaces in this setup are vlan interfaces (not sure if that matters). I will reiterate that all of this worked prior to upgrading to 2.1 release.
-
I had the same problem while upgrading from 2.0.1 to 2.1.0. After some digging on the subject I've realized that the problem is probably associated with <negate_networks>table. Quick comparison of /etc/inc/filter.inc shows that version 2.0.1 inserts directly connected networks into <negate_networks>table:
/* add a Negate_networks table */ $natrules .= "table <negate_networks>{"; if($direct_networks_list) $natrules .= " $direct_networks_list "; if($vpns_list) $natrules .= " $vpns_list "; $natrules .= "}\n";</negate_networks>while in 2.1.0 this piece of code is missing:
/* add a Negate_networks table */ $aliases .= "table <negate_networks>"; if($vpns_list) $aliases .= "{ $vpns_list }"; $aliases .= "\n";</negate_networks>I suspect that this is the cause of problem. The change isn't mentioned at "New Feature and Changes" (https://doc.pfsense.org/index.php/2.1_New_Features_and_Changes#NAT.2FFirewall_Rules.2FAlias) but one can see that it was made by user ermal on Nov 16, 2012 (https://github.com/pfsense/pfsense/commit/b4227df690fb7a989ead9b3928ebaaaa34b495eb
Edit: To clarify the role of <negate_networks>: pfSense is using this table in auto created rules that are connected to user rules with policy routing.
Regards,
John</negate_networks></negate_networks></negate_networks> -
Great job John!
I think we have just to wait and see… and hope some developer take care of it...
I had the same problem while upgrading from 2.0.1 to 2.1.0. ….
why "had"?
How did you solve it? Maybe replacing code on filter.inc? -
We do not know the reason of modifying <negate_networks>so it's probably better to add rule using GUI. For example if you have custom rule:
pass in quick on $LAN $GWFailOverGW from $AllowedLocalNets to any keep state label "USER_RULE: allow ... "add the following one just BEFORE above rule:
pass in quick on $LAN from $AllowedLocalNets to $DirectlyConnectedNets keep state label "My negate policy routing for destination"where
$AllowedLocalNets and $DirectlyConnectedNets are custom aliases.Regards,
John</negate_networks> -
why "had"?
How did you solve it? Maybe replacing code on filter.inc?I've simply reverted to redundant live copy of 2.0.1 release. English isn't my native language, so forgive me for any inaccuracy.
Regards,
john
