From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@lists.netfilter.org>
Subject: Re: SNAT before IPSec
Date: Thu, 07 Jun 2007 13:03:54 -0500 [thread overview]
Message-ID: <4668488A.8040102@riverviewtech.net> (raw)
In-Reply-To: <46683B69.8000303@riverviewtech.net>
On 06/07/07 12:07, Grant Taylor wrote:
> iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to
> A.B.C.x/24
> iptables -t nat -A POSTROUTING -o $LAN -s A.B.C.x/24 -j NETMAP --to
> D.E.F.x/24
>
> This should cause the NETMAPing to happen at the remote end of the vpn
> link and (hopefully) not confuse the router at the local end of the vpn
> link.
I've done some more thinking and I think it would be better to do the SNAT at the local end of the vpn link. Doing the SNAT on the remote end will work, but it is not as scalable as doing it on the local end.
If you consider your situation where you have multiple networks (3 or more) that are all the same subnet that you want to tie together, you have to SNAT and DNAT for each network. DNATing should be done at the remove end to change from the bogus address to the real address. If SNATing is done at the remove end, the remote end will have to have rules for each and every other network to know what to SNAT to. If SNATing is done at the local end, the local router knows what to SNAT to and the remote end will just DNAT and reply. So a slightly modified version of the above rules would be:
iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to A.B.C.x/24
iptables -t nat -A POSTROUTING -o $WAN -d D.E.N.x/16 -j NETMAP --to D.E.M.x/24
Where D.E.N.x/16 is the larger class B that encompasses all remote networks. I.e. selectively SNAT only when you are going to a remote network.
Where D.E.M.x/24 is the local bogus network.
This *SHOULD* allow you to have two rules on each system to allow all of them to communicate with each other presuming that they have routes for the D.E.N.x/16 (sub)network(s), be it an ethernet link, IPSec VPN, ATM WAN, or what ever.
Grant. . . .
next prev parent reply other threads:[~2007-06-07 18:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-05 12:29 SNAT before IPSec noa levy
2007-06-05 12:56 ` Yasuyuki KOZAKAI
2007-06-05 14:36 ` Grant Taylor
2007-06-05 20:15 ` Jorge Davila
2007-06-05 20:28 ` Grant Taylor
2007-06-05 20:45 ` Jorge Davila
2007-06-05 23:53 ` Grant Taylor
2007-06-06 15:39 ` Jorge Davila
2007-06-06 18:48 ` Grant Taylor
2007-06-05 21:29 ` noa levy
2007-06-05 22:40 ` Jorge Davila
2007-06-05 22:40 ` noa levy
2007-06-05 22:59 ` Jorge Davila
2007-06-05 23:05 ` noa levy
2007-06-06 15:47 ` Jorge Davila
2007-06-07 15:40 ` noa levy
2007-06-07 16:36 ` Jorge Davila
2007-06-07 17:07 ` Grant Taylor
2007-06-07 18:03 ` Grant Taylor [this message]
2007-06-07 20:57 ` Jorge Davila
2007-06-08 17:57 ` Grant Taylor
2007-06-05 22:43 ` Jorge Davila
-- strict thread matches above, loose matches on Subject: below --
2007-06-04 22:43 noa levy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4668488A.8040102@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=gtaylor+reply@riverviewtech.net \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.