IPSEC breaks outgoing Loadbalance
-
I've traced the problem back to the rule that is inserted before the load balance user rule:
pass in quick on $LAN from any to <vpns> keep state label "NEGATE_ROUTE: Negate policy route for vpn(s)"</vpns>The problem is that the <vpn>table is:
table <vpns> { 0.0.0.0/0 }</vpns>The code does not identify the IPSEC's address pool, same as in the IPSEC overview page.
$ph2ent['remoteid'] ```does not do what it is supposed to do.</vpn> -
Shuold be fixed in newer snapshots.
-
Thanks. Do you have a link to the commit with the fix? I want to integrate this fix in myself because everything I have is so stable right now. I will wait until final before I upgrade.
Cheers!
-
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/1ee3ed0f4c16c2d2b08d0db2426bcbfec7a61059
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/d9a417f8f4068da48d6faad37080ebfa4216a470 -
I integrated these fixes and found that the table <vpns>was no longer created which is good but the rule inserted above the load balancing rule still refers to <vpns>and that causes the system to still route everything through default gateway.
I took out the code to generate the rule for now and all is ok. Was the intention of the rule is to route through default gateway if the destination is part of the VPN subnet? My IPSEC clients get 192.168.50.1 so should the rule really point to that?
Cheers!</vpns></vpns>
-
You could even flushed the vpns table and be done with it without patching.
Diagnostic->Tables