IPsec and optional interface support
-
Good Day,
I was wondering if there is any way to prioritize local traffic before the IPsec VPN traffic. Currently, the setup I have now is two Pfsense 1.2.3 boxes with a IPsec VPN fully functional and working. on the LAN of one firewall, I have 4 optional vlan interfaces. Currently, I have no rules set up on the optional interfaces to allow all traffic to pass for trouble shooting.
The issue is where the traffic is being sent. Currently, if I was to take down the VPN, I am fully able to ping any host on the first optional interface from any other optional interface and vice versa. When the VPN is up, I loose all inter-vlan routing capabilities. It appears all the traffic gets shipped out the VPN before getting parsed locally on the firewall which causes inter-vlan connection issues. All clients have internet functionality as well as access to resources on the other side of the vpn. I have checked the routing table of pfsense and all the routes are currently in place for the optional interfaces.
Is my logic wrong or am I heading in the wrong path, any help is greatly appreciated!
Current Diagram:
10.0.0.0/8 [PFsense] <====IPsec==> [Pfsense] –>[Procurve 2600] –>optional Lan interfaces (10.30.1.x /24 etc)
-
Sounds like your subnet mask is way too wide for the remote side of the VPN tunnel. Do you really need 10/8?
The way IPsec works, it isn't possible to have 10/8 on the far side of the tunnel and still use anything under 10/8 locally.
-
jimp,
Thanks for the comment. I read on the pfsense tutorials the limitations of IPsec and overlapping IP address space. It never really dawned on me that the /8 was too broad. I do have resources that would be helpful to be reached on the full /8 segment, however, once I changed the address space to something that didn't overlap all was well. Thanks for your help!
In addition, I was under the impression that because the local routes are in the pfsense routing table it would take precedence over VPN traffic. Case in point, all traffic was being shot out of the VPN because of the broad address range. Now I know how the internals of pfsense works, which in turn has helped me understand how it performs traffic routing.
Thanks,
Rob
-
Thanks for the comment. I read on the pfsense tutorials the limitations of IPsec and overlapping IP address space. It never really dawned on me that the /8 was too broad. I do have resources that would be helpful to be reached on the full /8 segment, however, once I changed the address space to something that didn't overlap all was well. Thanks for your help!
You're welcome :)
In addition, I was under the impression that because the local routes are in the pfsense routing table it would take precedence over VPN traffic. Case in point, all traffic was being shot out of the VPN because of the broad address range. Now I know how the internals of pfsense works, which in turn has helped me understand how it performs traffic routing.
The way IPsec works, it just grabs the data in-kernel before the routing table is even consulted. That's just a side effect of how it works under FreeBSD (and probably other OS implementations). If you were using OpenVPN instead, you can selectively route things a lot cleaner, and the routing table is respected (though you still can't overlap subnets).
