Packages not routed over IPSEC but going out on WAN
-
For some specials needs I have two Pfsense boxes interconnected with a /30 network. Both boxes have a bunch of other interfaces/subnets. All subnets that has to reach each other can do so, even between the boxes by use of static routes.
Box 1 has an IPSEC VPN connected, with multiple phase2's covering subnets living on both box 1 as box2. Firewall rules are in place and I can reach all subnets living on box1 over the IPSEC connection.
However, subnets living on box 2 seem to have a problem with the return path. Doing packet captures I can see packages coming in over the IPSEC, going over the interconnection interfaces on both boxes, and going to the interface the subnet is living on box 2. Then the return path can be followed until the interconnection interface on box 1. The packet capture there shows a source and destination network defined as a phase2 in the IPSEC connection. However, the packages seem to be going to WAN instead of IPSEC, ending up nowhere of course.
I have no idea how to make these packages going back also over IPSEC. It can’t and shouldn’t be done with static routes, as far as know of.
Any ideas here?
-
Please do not cross-post to multiple topic forums.
-
I did cross-post because I'm unsure if it is a routing or IPSEC issue.
I'll try to make a diagram to clearify things.
Have been thinking though, is it possible it that it's not working because box1, running the IPSEC doesn't have an interface in the source subnet itself? The source subnet (as seen correctly on the packet capture)is living on box2 -
See attached diagram
By the use of packet capture it can be seen that traffic from 10.e.f.100 to 192.a.b.0/24 is flowing through pfsense2 and then by use of a static route going to pfsense1 (over the interconnection /30 network). Then pfsense1 routes the packages over the WAN instead of IPSEC although 10.e.f.0/24 <–> 192.a.b.0/24 is defined as a phase2 on IPSEC.
The incoming path seems to be fine, only outgoing is going over WAN and not over IPSEC.Why is the traffic not routed over IPSEC and how can I correct this?
From 10.c.d.100 I have no problem at all, 10.c.d.0/24 <--> 192.a.b.0/24 is defined exactly the same as a phase2.
-
Why are you obfuscating private addresses? It accomplishes nothing except making more work for everyone involved. Including you.
-
Did you create a static route on pfSense2 directing 192.a.b.0/24 to gateway 10.x.y.253?
Alternately you could edit the transit interface that is assigned the 10.x.y.254 address on pfsense2 and add an upstream gateway to 10.x.y.253 there.
Then all traffic arriving through that interface will be tagged with reply-to and reply traffic will be forced back out that way.
-
Did you create a static route on pfSense2 directing 192.a.b.0/24 to gateway 10.x.y.253?
Yes, I did. And as said, doing a packet capture I can see the traffic arriving on 10.x.y.253 and from there going to the WAN of pfsense1
Alternately you could edit the transit interface that is assigned the 10.x.y.254 address on pfsense2 and add an upstream gateway to 10.x.y.253 there.
Then all traffic arriving through that interface will be tagged with reply-to and reply traffic will be forced back out that way.
I'm gonna give that a try to see how it goes and will post the result. Tnx for the hint!
-
Nothing I said will help with what is happening on pfsense 1.
You are going to have to post more details about what you have done (like screen shots of rules, SPDs, etc.
Like I said. I built it and it worked first time.
pfSense A 2.3.2_1, pfSense C reasonably-current 2.4-BETA.
-
See screenshots from pfsense 1 SPDs and packet captures from transit interface en WAN interface.
I start a ping from 10.95.95.103 connected to pfsense2, to 192.168.1.5. Traffic is coming on the transit interface on pfsense1. A package capture om IPSEC shows up empty when filtering on 192.168.1.5. But 192.168.1.5 is seen on a WAN capture instead.
As the SPD's clearly shows 192.168.0.0/23 it should go through IPSEC.
![packet capture transit interface pfsense 1.jpg](/public/imported_attachments/1/packet capture transit interface pfsense 1.jpg)
![packet capture transit interface pfsense 1.jpg_thumb](/public/imported_attachments/1/packet capture transit interface pfsense 1.jpg_thumb)
![packet capture WAN interface pfsense 1.jpg](/public/imported_attachments/1/packet capture WAN interface pfsense 1.jpg)
![packet capture WAN interface pfsense 1.jpg_thumb](/public/imported_attachments/1/packet capture WAN interface pfsense 1.jpg_thumb) -
Here's a traceroute from 10.95.95.103 to 192.168.1.5. After reaching the transit interface on pfsense1 is goes out on the internet instead of over IPSEC
-
SOLVED!
After looking again I finally realised my phase 2 was 10.95.0.0/16 on one side and 10.95.00/23 on the other. That doesn't include 10.95.95.103….
So it is going to WAN instead.I'll have a second look on tcp/ip for dummies :(
Sorry for the waste of time.What surprises me highly though is that a phase2 is established, even though there is a subnet mismatch. The SPD established is 10.95.00/23, likely because that fits in 10.95.0.0/16. I always understood that in case of a mismatch it would fail at all. In that case the cause was much more clear.