From: llee_at_battalion.nexxis.net
Date: Fri Dec 13 2002 - 08:24:13 CET
Sam,
Thanks for confirming what I thought the problem was. After tinkering
with the iptable rules, I was able to get this to work. There's plenty of
documentation in Freeswan indicating that NAT will mangle the packets but
only in relation to MASQ. Since those examples were targeted to users
using the ppp0 interface, it doesn't really apply to a static IP setup.
For anyone interested in knowing the proper statement for a static IP
setup use the iptables rule:
iptables -t nat -A POSTROUTING -o $INET_IFACE -d $TARGET_NET -j ACCEPT
iptables -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
where:
$INET_IFACE = eth0, eth1, etc... (which ever interface is directly
connected to the Internet)
$TARGET_NET = 10.0.0.0/24 (the destination subnet for your VPN packets)
$INET_IP = the public static IP address for your gateway box.
Thanks again Sam...and I hope this helps anyone else who needs it.
Lone
On Wed, 11 Dec 2002, Sam Sgro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> On Wed, 11 Dec 2002 llee_at_battalion.nexxis.net wrote:
>
> > When I try to ping computers from one protected subnet to the other, I get
> > an interesting result. Here an excerpt of /proc/net/dev on each gateway:
> >
> > The Source Gateway:
> > Inter-| Transmit
> > face |bytes packets errs drop fifo colls carrier compressed
> > ipsec0: 504 4 0 0 0 0 0 0
> >
> > The Destination Gateway:
> > Inter-| Receive
> > face |bytes packets errs drop fifo frame compressed multicast
> > ipsec0: 240 4 0 0 0 0 0 0
> >
> > I am assuming the ping packets from the source gateway should end up being
> > the same size as the packets received on the destination gateway. So the
> > packets are getting mangled somewhere. I'm not using Masquerading, my
> > SNAT statement for iptables is:
> >
> > $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
> >
> > for both boxes. Is it possible that SNAT is mangling the packets, if so,
> > how do I change my iptables statement to allow VPN-ed packets to pass
> > through cleanly. If this isn't the problem, what might be a possible
> > cause? Thanks in advance for any help.
>
> SNAT'ting would be the first culprit I would point to. Generally speaking, for
> a NAT-to-NAT VPN setup to work, you need to exempt packets destined for the
> opposing subnet from NAT.
>
> http://lists.freeswan.org/pipermail/users/2002-August/012918.html
>
> Add "-d \! 1.2.3.0/24", where 1.2.3.0/24 is the opposing subnet.
>
> Another alternative: remove the SNAT rule temporarily. IPSec processing will
> provide its own form of NAT, and although you wouldn't be able to speak with
> the rest of the 'net, it should exclude that rule from being the source of
> your trouble.
>
> - --
> Sam Sgro
> sam_at_freeswan.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: noconv
> Comment: For the matching public key, finger the Reply-To: address.
>
> iQCVAwUBPfcJyEOSC4btEQUtAQHecwQAowHbkg7mRLwTVxeNmvl+frhKGvH3Erzd
> GxlqDhmaAOiy/soguGkBjgvvs6pA5jIxgoZFWrkw0072McwFK8cgO58EWdPpUUdY
> lgroUN+6Ew3g8aZd14eYmZBFixts9JInn9ldZg2FTlV6JkSFa5SyigsLSnhLxTvX
> UeX4tiX4kdY=
> =Ajf5
> -----END PGP SIGNATURE-----
>
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Fri Dec 13 2002 - 05:21:18 CET