On Nov 18, 2011, at 2:06 AM, Nico Williams wrote: > 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 :)
Yeah, except without those pesky APIs. :-) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
