| From: Chris Wilson <chris_at_netservers.co.uk>
| > The problem is that the other side was 62.227.169.222, but it sent an
| > ID payload of 192.168.10.111. Pluto requires that the peer
| > represented by %any must send its IP address as the ID (unless an ID
| > is specified in the conn).
| >
| > Why did the peer identify itself as 192.168.10.111?
|
| I have seen this happen when connections are going through NAT. Would it
| be possible to fix/patch/break Pluto so that it can accept (and ignore)
| any IP address in the ID field, and respond to the address the packets are
| coming from? It would be very useful for road warriors behind NAT.
I'm reluctant to make authentication logic more liberal -- it might be
more insecure.
The problem will crop up again anyway when the IPSEC traffic flows:
the wrong IP addresses will be used.
NAT changes packets; we protect against changed packets.
This is a design issue, and one that should be considered in a
comprehensive way. It affects KLIPS and Pluto.
Hugh Redelmeier
hugh_at_mimosa.com voice: +1 416 482-8253
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:46 CEST