Bug #8551
closedRouted IPsec/VTI is unable to communicate from the ipsecX interface address to a routed target
100%
Description
Breaking this away from #8544 since the feature in general works aside from this separate issue.
With routed IPsec, the VTI interface (e.g. ipsec1000) has its own address. This address can communicate with its peer at the other end of the tunnel OK, but it cannot reach a subnet routed to the peer. The packet appears on the ipsecX and enc0 interfaces but no outbound ESP packet is generated for it, as if it did not match.
Communicating LAN to LAN routed across the ipsecX interface works as expected, only communication from firewall A to the LAN subnet(s) or beyond at firewall B fails. Setting a source address for ping or ssh to a LAN address enables the firewall to reach the remote LAN, similar to what was needed for tunneled IPsec in the same situation, but in this case the firewall is picking the correct source.
It's not a regression since the behavior is similar to previous behavior, so it's not a huge problem, but it would be nice to solve it if we can.
More info at https://forum.netgate.com/topic/131420/routed-ipsec-using-if_ipsec-vti-interfaces/25
Updated by Jim Pingle over 6 years ago
This appears to be related to the automatic rules to pass traffic out from the firewall itself, for example:
pass out route-to ( ipsec5000 10.6.106.1 ) from 10.6.106.2 to !10.6.106.0/24 tracker 1000010116 keep state allow-opts label "let out anything from firewall host itself"
If I remove the route-to ( ipsec5000 10.6.106.1 )
portion of the above rule, it works. I need to do some more tests to see if it affects all route-to traffic or only this case.
Updated by Jim Pingle over 6 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset a273f7bdff455a50156ab004358ba3909fa1fee7.