NAT rule

NAT rule

[Michael Crider]

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?
-- 
Michael Crider

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: NAT rule

[Jan Engelhardt]

On Wednesday 2008-07-16 18: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?


iptables -t nat -A POSTROUTING -m policy --dir out --mode tunnel 
--tunnel-dst <realip of vendor> -j NETMAP --to 192.168.101.0/24
iptables -t nat -A PREROUTING -m policy --dir in --mode tunnel
--tunnel-src <realip of vendor> -j NETMAP --to 192.168.10.0/24

Re: NAT rule

[Grant Taylor]

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. . . .

Re: NAT rule

[Grant Taylor]

On 07/16/08 11:54, Jan Engelhardt wrote:
> iptables -t nat -A POSTROUTING -m policy --dir out --mode tunnel 
> --tunnel-dst <realip of vendor> -j NETMAP --to 192.168.101.0/24
> iptables -t nat -A PREROUTING -m policy --dir in --mode tunnel
> --tunnel-src <realip of vendor> -j NETMAP --to 192.168.10.0/24

How does this take in to account that there is very likely an IP address 
conflict between the local side of the VPN and the remote side of the 
VPN?  I'm very much afraid that the local server will just try to talk 
to a local IP thinking that it is replying directly back to the original 
client.



Grant. . . .

Re: NAT rule

[Jan Engelhardt]

On Wednesday 2008-07-16 19:19, Grant Taylor wrote:

> On 07/16/08 11:54, Jan Engelhardt wrote:
>> iptables -t nat -A POSTROUTING -m policy --dir out --mode tunnel --tunnel-dst
>> <realip of vendor> -j NETMAP --to 192.168.101.0/24
>> iptables -t nat -A PREROUTING -m policy --dir in --mode tunnel
>> --tunnel-src <realip of vendor> -j NETMAP --to 192.168.10.0/24
>
> How does this take in to account that there is very likely an IP
> address conflict between the local side of the VPN and the remote
> side of the VPN?  I'm very much afraid that the local server will
> just try to talk to a local IP thinking that it is replying
> directly back to the original client.

Packets already destined for the tunnel (see first rule)
are not rerouted, because, well, it's POSTrouting.

Re: NAT rule

[Grant Taylor]

On 07/16/08 12:18, Taylor, Grant wrote:
> 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.

This is what you have now.

+---------+   +--------+           +--------+       +--------+
| Support +---+ Router +===(VPN)===+ Router +---+---+ Server |
+---------+   +--------+           +--------+   L   +--------+
                                                 A
                                                 N   +-------+
                                                 +---+ Other |
                                                     +-------+


This is what I'm proposing.

                                    +--------+       +--------+
+---------+   +--------+           | Router +-<>-<>-+ Server |
| Support +---+ Router +===(VPN)===+        +---+---+        |
+---------+   +--------+           +--------+   L   +--------+
                                                 A
                                                 N   +-------+
                                                 +---+ Other |
                                                     +-------+

In this case the VPN comes in and goes directly to the small network 
that is the router and server, leaving the rest of your LAN alone.



Grant. . . .

Re: NAT rule

[Grant Taylor]

On 07/16/08 12:25, Jan Engelhardt wrote:
> Packets already destined for the tunnel (see first rule) are not 
> rerouted, because, well, it's POSTrouting.

By the time packets would make it to your rule, yes.  My concern is that 
the router / VPN setup will see one subnet on one ethernet interface and 
the same subnet on the other end of the tunnel.  At least that is the 
understanding that I got from the OP.  So my concern is not so much 
confusion on IPTables part so much as it is a simple routing (which 
interface gets used) seeing the same subnet in two different locations.

I guess I should ask, how well will the router handle having the same 
subnet addresses in two different (non connected) locations, one being 
the ethernet interface and the other being through the tunnel?




Grant. . . .

Re: NAT rule

[Michael Crider]

Thank you, Jan, for taking the time to come up with rules that would do 
exactly what I was asking. Thank you, Grant, for thinking outside the 
box. I implemented your suggestion and it works perfectly.
-- 
Michael Crider

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: NAT rule

[Grant Taylor]

On 07/16/08 14:22, Michael Crider wrote:
> Thank you, Jan, for taking the time to come up with rules that would do 
> exactly what I was asking. Thank you, Grant, for thinking outside the 
> box. I implemented your suggestion and it works perfectly.

You are welcome.  I'm glad that things are working the way they need to.

And as an added benefit with the second network, you don't have to worry 
about keeping them from connecting to other hosts.  Of course depending 
on what access they have to the target system they can still bounce 
elsewhere. :s  But with a VPN, they are just about in any way.



Grant. . . .