On Wed, Nov 16, 2011 at 8:17 PM, Yoav Nir <y...@checkpoint.com> wrote: > On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote: >>> But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs >>> are static, so there is only one peer where a particular source IP might >>> come from. >> >> Openswan supports MARKing the packet based on which SPI the packet >> came out of, ip_conntrack then follows its around and reply packets >> get the MARK as well, so we know which tunnel to send it to despite the >> overlapping IP address on the client end. We even provide a setsockopt() >> option so you MARK your socket before connecting to 192.168.1.1 and the >> kernel knows which SPI to send the packet to. And each IPsec policy can >> optin to allowing a range that would overlap. > > Yeah, we do something similar. We are a stateful firewall, so every packet is > associated with a "connection" (well defined for TCP, SCTP; kind of bogus for > UDP), and every connection is associated with a tunnel, so outbound packets > get to use the correct SA (or at least one matching the SA that inbound > packets came through).
Oh, this is good news. It means you're both close to having RFC5660 implemented :) Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
