Packages not routed over IPSEC but going out on WAN
-
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.
 -
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.
