From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: NAT rule
Date: Wed, 16 Jul 2008 12:18:04 -0500 [thread overview]
Message-ID: <487E2D4C.5000506@riverviewtech.net> (raw)
In-Reply-To: <487E1DF3.1090203@hoecoop.org>
On 07/16/08 11:12, Michael Crider wrote:
> I am attempting to set up a LAN-to-LAN VPN using ipsec-tools for one of
> our vendors to access a server behind our firewall. However, the local
> IP address of the server (192.168.10.xx) conflicts with a local address
> at the vendor's network. They suggested using NAT to transform the
> server address to 192.168.101.xx and hooking the VPN to the
> 192.168.101.0/24 network. I would like to run the VPN on the same
> machine with the firewall (which uses netfilter 1.3.5-4 on CentOS 5.2).
> We need to be able to initiate a connection from either end of the VPN.
> Could anybody recommend iptables rules that would set up the address
> translation?
This really sounds like an IP address conflict between your side of the
VPN and the vendors side of the VPN. Presuming that this is indeed the
case you will need to address this issue before you try to do the VPN or
things will get very harry.
Based on the statement "... They suggested using NAT to transform the
server address to 192.168.101.xx and hooking the VPN to the
192.168.101.0/24 network. ..." it sounds like they are encouraging you
to add a second subnet (192.168.101.x/24) and having them access it.
That way they will VPN from what ever subnet they have to your new
192.168.101.x/24 subnet where they will connect to the server.
If this is indeed the case, you could easily add the additional subnet
to your configuration as an alias. That way all that needs to be done
is to set up the VPN from their office / subnet to your office / new
subnet. NATing would not even need to be involved. If this will
fulfill their needs this is actually quite simple to do. Add a new
subnet to an alias on the server in question and to the VPN router the
server uses as its gateway. On the server you would need to add a route
to the remote network via the new 192.168.101.x/24 address of the
router. This will ensure that the server will continue using your
existing default gateway's IP address to get to the general internet.
In short, add a new IP to two pieces of equipment, set up the VPN, and
add a single route statement to the target server and you are done.
Grant. . . .
next prev parent reply other threads:[~2008-07-16 17:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 16:12 NAT rule Michael Crider
2008-07-16 16:54 ` Jan Engelhardt
2008-07-16 17:19 ` Grant Taylor
2008-07-16 17:25 ` Jan Engelhardt
2008-07-16 18:49 ` Grant Taylor
2008-07-16 17:18 ` Grant Taylor [this message]
2008-07-16 17:26 ` Grant Taylor
-- strict thread matches above, loose matches on Subject: below --
2008-07-16 19:22 Michael Crider
2008-07-16 19:31 ` Grant Taylor
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=487E2D4C.5000506@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=netfilter@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox