Bug #4174
closedmulti-WAN IPsec uses wrong interface at times
100%
Description
Still quantifying exactly what's happening here, it's hit and miss. Some ISAKMP and/or ESP traffic ends up following the system routing table rather than the route-to/reply-to rules added to match that traffic. 2.1x added static routes for IPsec endpoints via the appropriate gateway, which made this work without needing route-to/reply-to. In 2.2, you'll end up with some ISAKMP and/or ESP traffic leaving the interface where the default gateway resides, with a diff WAN's IP as the source.
Updated by Jim Thompson almost 10 years ago
Do you have a test case setup?
When you do, let's assign this to Ermal.
Updated by Chris Buechler almost 10 years ago
I'm testing on a production system where I've been looking into a separate IPsec issue as well. Now setting up a test case on our own systems.
The situation seems to be anything egress goes the wrong way (not matching the "pass out ... route-to"), but ingress does match the reply-to. In this particular production case it doesn't matter either way as it's the same ISP on both WANs and they pass the traffic to the Internet via either connection regardless of source IP. That'll be clearer once a controlled test setup is in place to replicate.
Updated by Chris Buechler almost 10 years ago
- Assignee changed from Chris Buechler to Ermal Luçi
test setup details on the IPsec test list wiki page
Updated by Chris Buechler almost 10 years ago
the specific issue is the "pass out" isn't getting routed out via the correct interface. As responder it's fine, as initiator, traffic follows default route
Updated by Chris Buechler almost 10 years ago
Ermal: the test box at 172.27.44.52 has the test case setup we talked about earlier, where the "pass out" rules specify no interface. As I mentioned, it makes no diff. Go to Status>IPsec on there and try to connect a couple VPNs and you'll see.
: pfctl -ss | grep 500 vmx0 udp 192.0.2.77:500 -> 100.64.25.20:500 SINGLE:NO_TRAFFIC vmx0 udp 198.51.100.77:500 -> 100.64.25.21:500 SINGLE:NO_TRAFFIC
following default route.
If you don't see something quickly there, let's just bring back the static routes used in every prior version, and we can revisit eliminating the need for those post-2.2.
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
Updated by Chris Buechler almost 10 years ago
- Assignee changed from Ermal Luçi to Chris Buechler
to me for further testing
Updated by Ermal Luçi almost 10 years ago
- % Done changed from 0 to 100
Applied in changeset ac8f75f1e046b32c88693ff0c6854b7f641cf206.
Updated by Ermal Luçi almost 10 years ago
Applied in changeset 2ecb2dafa5fa78388fd72c3360495f734cb5633c.