several people have reported problems establishing a tunnel in a
configuraton like this:
client -- masquerading --( inter )-- frees/wan -- protected
gateway net gateway network
the trouble is due to the masquerading gateway mapping the client's inital
isakmp traffic to a higher source port, while frees/wan expects it to be
udp port 500. thus the incoming tunnel/keying requests are dropped and a
security association isn't created. however, this problem can easily be
circumvented on the frees/wan gateway side by remapping the incoming isakmp
traffic to source port 500. using eg. a netfilter/iptables firewall between
the gateway and the internet, this can be achieved by means of the
following rule
> iptables -t nat -A POSTROUTING -p udp --sport ! 500 \
-d $ipsecGatewayIP --dport 500 -j SNAT --to :500
with assistance of such "re-masquerading", i managed to successfully
initiate a security association from the masqueraded client:
:
: STATE_QUICK_R2: IPsec SA established
:
without re-masquerading, the same client/gateway configuration would fail:
:
: packet from $masqIP:63890: initial Main Mode message received on
: $ipsecGatewayIP:500 but no connection has been authorized"
:
it was already pointed out on this list that special care has to be taken
in configuring such a connection. while on the client (left) side, you
could simply put
:
: conn example
: left=%defaultroute
:
on the gateway (right) side you'd have to put
:
: conn example
: left=%any # left=$masqIP would also do
: leftsubnet=$clientIP/32 # this line is IMPORTANT
:
leaving out the leftsubnet line would result in leftsubnet=left=$masqIP.
unfortunately, i wasn't able to use the established tunnel, because no
esp/ip proto 50 traffic would make it through my masquerading gateway
(linux 2.2.19, ipchains). consulting the VPN-Masquerade-HOWTO i learnt that
ipchains can only masquerade esp traffic by means of a special module
(ip_masq_ipsec.o). with that module, however, the isakmp traffic wouldn't
be masqueraded to a high port in first place, thus there isn't really any
need for "re-masquerading" on the frees/wan gateway side when masquerading
is done by ipchains and ip_masq_ipsec.o. i checked it out and, quite
amazingly, it worked like a charm.
i haven't got any other masquerading gateway at hands right now. however, i
shall shortly look into an environment with netfilter/iptables as
masquerading gateway. it seems as if netfilter masquerades esp traffic
without special precautions, and thus a workaround like outlined here could
still be useful. opinions? i'd appreciate your comments.
sven
(strip no. and .spam from my email address for personal replies)
_______________________________________________
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:58 CEST