Linux Netfilter discussions
 help / color / mirror / Atom feed
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. . . .

  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