RE: NAT issues on a VPN tunnel

RE: NAT issues on a VPN tunnel

[Christopher Lyon]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Jason Opperisano
> Sent: Tuesday, November 02, 2004 4:24 PM
> To: netfilter@lists.netfilter.org
> Subject: Re: NAT issues on a VPN tunnel
> 
> On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> > So, I am trying to use NAT to solve the problem below because of an
IP
> > addressing conflict issue but I am not having much luck. Basically
all
> of
> > the Site A needs to get to only a few devices at each site B&C so I
am
> > trying to do PREROUTING NAT on the far end systems.
> 
> try doing it with POSTROUTING on the local system (site a).

I believe that would cause a problem on the VPN tunnel as the endpoints
won't match. This would need to be done on the far end (site b). 

> 
> -j
> 
> --
> "I bent my wookie."
> 	--The Simpsons
> 
> 

RE: NAT issues on a VPN tunnel

[Jason Opperisano]

On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> I believe that would cause a problem on the VPN tunnel as the endpoints
> won't match. This would need to be done on the far end (site b). 

believe what you want--it works for me.

-j

--
"Eww, Daddy, this tastes like Gramma!"
	--The Simpsons

RE: NAT issues on a VPN tunnel

[John A. Sullivan III]

On Tue, 2004-11-02 at 21:43, Jason Opperisano wrote:
> On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> > I believe that would cause a problem on the VPN tunnel as the endpoints
> > won't match. This would need to be done on the far end (site b). 
> 
> believe what you want--it works for me.
<snip>
It can be made to work from either side.  Isn't the tunnel end point the
public address of the gateway? Unless you mean that the internal 
network addresses of the IPSec Security Policies would not match.  I
would think that is true but I have never tried it; it sounds like Jason
has.  Jason, has your solution worked with IPSec?

I have generally found it easier to NAT at the side where the conflict
is being resolved especially if the conflicting network needs
connectivity to several gateways.  Moreover, it presents no SP
problems.  I have designed set ups where the NAT is done on the other
side as Jason suggests and with IPSec in the case where the admin did
not have control over the remote side but it is a little more
complicated - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Re: NAT issues on a VPN tunnel

[Jason Opperisano]

On Tue, Nov 02, 2004 at 11:03:53PM -0800, Chris Lyon wrote:
> > On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> > > I believe that would cause a problem on the VPN tunnel as the endpoints
> > > won't match. This would need to be done on the far end (site b).
> > 
> > believe what you want--it works for me.
> 
> So how do you build the tunnel?

the tunnel is built between the public external IP's of the two
gateways.

in a scenario where site A and site B both use 10.0.0.0/24 as their
internal network, and we need to build a VPN between them:

-------
Site A
-------
ipsec.conf:
  leftsubnet=172.31.1.0/24
  rightsubnet=172.31.2.0/24

# map our 10.0.0.0/24 to 172.31.1.0/24 when going over the VPN
iptables -t nat -A POSTROUTING -o ipsec0 \
  -s 10.0.0.0/24 -j NETMAP --to 172.31.1.0/24

# unmap packets from the other side to 172.31.1.0/24 to our 10.0.0.0/24
iptables -t nat -A PREROUTING -i ipsec0 \
  -d 172.31.1.0/24 -j NETMAP --to 10.0.0.0/24
   
-------
Site B
-------
ipsec.conf:
  leftsubnet=172.31.2.0/24
  rightsubnet=172.31.1.0/24

# map our 10.0.0.0/24 to 172.31.2.0/24 when going over the VPN
iptables -t nat -A POSTROUTING -o ipsec0 \
  -s 10.0.0.0/24 -j NETMAP --to 172.31.2.0/24

# unmap packets from the other side to 172.31.2.0/24 to our 10.0.0.0/24
iptables -t nat -A PREROUTING -i ipsec0 \
  -d 172.31.2.0/24 -j NETMAP --to 10.0.0.0/24

when someone in site A needs to connect to 10.0.0.100 in site B, they
connect to 172.31.2.100.

when someone in site B needs to connect to 10.0.0.100 in site A, they
connect to 172.31.1.100.

keep in mind that that packets are sent over the tunnel based on their
destination address, not their source address.  also keep in mind that
the packets are still in the clear on ipsec* interfaces and encrypted on
the physical interfaces.

dunno if this helps any, but it works for me.  this is how it makes
sense to me in my head--that each side should perform it's own
chicanery.  i'm not saying it can't be made to work some other way.

-j

--
"'Nuke the whales?' You don't really believe that, do you?
 I dunno. Gotta nuke something."
        --The Simpsons

RE: NAT issues on a VPN tunnel

[Chris Lyon]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Jason Opperisano
> Sent: Wednesday, November 03, 2004 7:49 AM
> To: netfilter@lists.netfilter.org
> Subject: Re: NAT issues on a VPN tunnel
> 
> On Tue, Nov 02, 2004 at 11:03:53PM -0800, Chris Lyon wrote:
> > > On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> > > > I believe that would cause a problem on the VPN tunnel as the
> endpoints
> > > > won't match. This would need to be done on the far end (site b).
> > >
> > > believe what you want--it works for me.
> >
> > So how do you build the tunnel?
> 
> the tunnel is built between the public external IP's of the two
> gateways.
> 
> in a scenario where site A and site B both use 10.0.0.0/24 as their
> internal network, and we need to build a VPN between them:


But that is not my case. I have three sites with the two remote sites being
in conflict. 

Site A 192.168.254.0/24
Site B 10.10.0.0/16
Site C 10.10.0.0/16

So, I would need to do the translation on the remote side, site B and site
C.

Correct? I can't see doing this at the head end.

> 
> -------
> Site A
> -------
> ipsec.conf:
>   leftsubnet=172.31.1.0/24
>   rightsubnet=172.31.2.0/24
> 
> # map our 10.0.0.0/24 to 172.31.1.0/24 when going over the VPN
> iptables -t nat -A POSTROUTING -o ipsec0 \
>   -s 10.0.0.0/24 -j NETMAP --to 172.31.1.0/24
> 
> # unmap packets from the other side to 172.31.1.0/24 to our 10.0.0.0/24
> iptables -t nat -A PREROUTING -i ipsec0 \
>   -d 172.31.1.0/24 -j NETMAP --to 10.0.0.0/24
> 
> -------
> Site B
> -------
> ipsec.conf:
>   leftsubnet=172.31.2.0/24
>   rightsubnet=172.31.1.0/24
> 
> # map our 10.0.0.0/24 to 172.31.2.0/24 when going over the VPN
> iptables -t nat -A POSTROUTING -o ipsec0 \
>   -s 10.0.0.0/24 -j NETMAP --to 172.31.2.0/24
> 
> # unmap packets from the other side to 172.31.2.0/24 to our 10.0.0.0/24
> iptables -t nat -A PREROUTING -i ipsec0 \
>   -d 172.31.2.0/24 -j NETMAP --to 10.0.0.0/24
> 
> when someone in site A needs to connect to 10.0.0.100 in site B, they
> connect to 172.31.2.100.
> 
> when someone in site B needs to connect to 10.0.0.100 in site A, they
> connect to 172.31.1.100.
> 
> keep in mind that that packets are sent over the tunnel based on their
> destination address, not their source address.  also keep in mind that
> the packets are still in the clear on ipsec* interfaces and encrypted on
> the physical interfaces.
> 
> dunno if this helps any, but it works for me.  this is how it makes
> sense to me in my head--that each side should perform it's own
> chicanery.  i'm not saying it can't be made to work some other way.
> 
> -j
> 
> --
> "'Nuke the whales?' You don't really believe that, do you?
>  I dunno. Gotta nuke something."
>         --The Simpsons
> 

RE: NAT issues on a VPN tunnel

[John A. Sullivan III]

You are correct in that the fact that the head end must know which of
the 10 nets to send its traffic.  It is easier to NAT at the conflicting
end.  It is possible to NAT at the head end but it is a little more
complicated.  I can explain how but a better use of the time may be to
find out why your current set up is not working.

Were you able to put the logging rules in place to see where in the
netfilter processing you are breaking? - John

On Fri, 2004-11-05 at 01:42, Chris Lyon wrote:
> > -----Original Message-----
> > From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> > bounces@lists.netfilter.org] On Behalf Of Jason Opperisano
> > Sent: Wednesday, November 03, 2004 7:49 AM
> > To: netfilter@lists.netfilter.org
> > Subject: Re: NAT issues on a VPN tunnel
> > 
> > On Tue, Nov 02, 2004 at 11:03:53PM -0800, Chris Lyon wrote:
> > > > On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> > > > > I believe that would cause a problem on the VPN tunnel as the
> > endpoints
> > > > > won't match. This would need to be done on the far end (site b).
> > > >
> > > > believe what you want--it works for me.
> > >
> > > So how do you build the tunnel?
> > 
> > the tunnel is built between the public external IP's of the two
> > gateways.
> > 
> > in a scenario where site A and site B both use 10.0.0.0/24 as their
> > internal network, and we need to build a VPN between them:
> 
> 
> But that is not my case. I have three sites with the two remote sites being
> in conflict. 
> 
> Site A 192.168.254.0/24
> Site B 10.10.0.0/16
> Site C 10.10.0.0/16
> 
> So, I would need to do the translation on the remote side, site B and site
> C.
> 
> Correct? I can't see doing this at the head end.
> 
> > 
> > -------
> > Site A
> > -------
> > ipsec.conf:
> >   leftsubnet=172.31.1.0/24
> >   rightsubnet=172.31.2.0/24
> > 
> > # map our 10.0.0.0/24 to 172.31.1.0/24 when going over the VPN
> > iptables -t nat -A POSTROUTING -o ipsec0 \
> >   -s 10.0.0.0/24 -j NETMAP --to 172.31.1.0/24
> > 
> > # unmap packets from the other side to 172.31.1.0/24 to our 10.0.0.0/24
> > iptables -t nat -A PREROUTING -i ipsec0 \
> >   -d 172.31.1.0/24 -j NETMAP --to 10.0.0.0/24
> > 
> > -------
> > Site B
> > -------
> > ipsec.conf:
> >   leftsubnet=172.31.2.0/24
> >   rightsubnet=172.31.1.0/24
> > 
> > # map our 10.0.0.0/24 to 172.31.2.0/24 when going over the VPN
> > iptables -t nat -A POSTROUTING -o ipsec0 \
> >   -s 10.0.0.0/24 -j NETMAP --to 172.31.2.0/24
> > 
> > # unmap packets from the other side to 172.31.2.0/24 to our 10.0.0.0/24
> > iptables -t nat -A PREROUTING -i ipsec0 \
> >   -d 172.31.2.0/24 -j NETMAP --to 10.0.0.0/24
> > 
> > when someone in site A needs to connect to 10.0.0.100 in site B, they
> > connect to 172.31.2.100.
> > 
> > when someone in site B needs to connect to 10.0.0.100 in site A, they
> > connect to 172.31.1.100.
> > 
> > keep in mind that that packets are sent over the tunnel based on their
> > destination address, not their source address.  also keep in mind that
> > the packets are still in the clear on ipsec* interfaces and encrypted on
> > the physical interfaces.
> > 
> > dunno if this helps any, but it works for me.  this is how it makes
> > sense to me in my head--that each side should perform it's own
> > chicanery.  i'm not saying it can't be made to work some other way.
> > 
> > -j
> > 
> > --
> > "'Nuke the whales?' You don't really believe that, do you?
> >  I dunno. Gotta nuke something."
> >         --The Simpsons
> > 
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

RE: NAT issues on a VPN tunnel

[Chris Lyon]

> -----Original Message-----
> From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> Sent: Friday, November 05, 2004 2:40 AM
> To: Christopher Lyon
> Cc: 'Jason Opperisano'; Netfilter users list
> Subject: RE: NAT issues on a VPN tunnel
> 
> You are correct in that the fact that the head end must know which of
> the 10 nets to send its traffic.  It is easier to NAT at the conflicting
> end.  It is possible to NAT at the head end but it is a little more
> complicated.  I can explain how but a better use of the time may be to
> find out why your current set up is not working.
> 
> Were you able to put the logging rules in place to see where in the
> netfilter processing you are breaking? - John


I am still trying to get a match rule going but it is saying something about
libipt_match.so not being loaded. I did try to load it but it can't so I am
digging around the kernel to find out what the hell is missing.

> 
> On Fri, 2004-11-05 at 01:42, Chris Lyon wrote:
> > > -----Original Message-----
> > > From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> > > bounces@lists.netfilter.org] On Behalf Of Jason Opperisano
> > > Sent: Wednesday, November 03, 2004 7:49 AM
> > > To: netfilter@lists.netfilter.org
> > > Subject: Re: NAT issues on a VPN tunnel
> > >
> > > On Tue, Nov 02, 2004 at 11:03:53PM -0800, Chris Lyon wrote:
> > > > > On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> > > > > > I believe that would cause a problem on the VPN tunnel as the
> > > endpoints
> > > > > > won't match. This would need to be done on the far end (site b).
> > > > >
> > > > > believe what you want--it works for me.
> > > >
> > > > So how do you build the tunnel?
> > >
> > > the tunnel is built between the public external IP's of the two
> > > gateways.
> > >
> > > in a scenario where site A and site B both use 10.0.0.0/24 as their
> > > internal network, and we need to build a VPN between them:
> >
> >
> > But that is not my case. I have three sites with the two remote sites
> being
> > in conflict.
> >
> > Site A 192.168.254.0/24
> > Site B 10.10.0.0/16
> > Site C 10.10.0.0/16
> >
> > So, I would need to do the translation on the remote side, site B and
> site
> > C.
> >
> > Correct? I can't see doing this at the head end.
> >
> > >
> > > -------
> > > Site A
> > > -------
> > > ipsec.conf:
> > >   leftsubnet=172.31.1.0/24
> > >   rightsubnet=172.31.2.0/24
> > >
> > > # map our 10.0.0.0/24 to 172.31.1.0/24 when going over the VPN
> > > iptables -t nat -A POSTROUTING -o ipsec0 \
> > >   -s 10.0.0.0/24 -j NETMAP --to 172.31.1.0/24
> > >
> > > # unmap packets from the other side to 172.31.1.0/24 to our
> 10.0.0.0/24
> > > iptables -t nat -A PREROUTING -i ipsec0 \
> > >   -d 172.31.1.0/24 -j NETMAP --to 10.0.0.0/24
> > >
> > > -------
> > > Site B
> > > -------
> > > ipsec.conf:
> > >   leftsubnet=172.31.2.0/24
> > >   rightsubnet=172.31.1.0/24
> > >
> > > # map our 10.0.0.0/24 to 172.31.2.0/24 when going over the VPN
> > > iptables -t nat -A POSTROUTING -o ipsec0 \
> > >   -s 10.0.0.0/24 -j NETMAP --to 172.31.2.0/24
> > >
> > > # unmap packets from the other side to 172.31.2.0/24 to our
> 10.0.0.0/24
> > > iptables -t nat -A PREROUTING -i ipsec0 \
> > >   -d 172.31.2.0/24 -j NETMAP --to 10.0.0.0/24
> > >
> > > when someone in site A needs to connect to 10.0.0.100 in site B, they
> > > connect to 172.31.2.100.
> > >
> > > when someone in site B needs to connect to 10.0.0.100 in site A, they
> > > connect to 172.31.1.100.
> > >
> > > keep in mind that that packets are sent over the tunnel based on their
> > > destination address, not their source address.  also keep in mind that
> > > the packets are still in the clear on ipsec* interfaces and encrypted
> on
> > > the physical interfaces.
> > >
> > > dunno if this helps any, but it works for me.  this is how it makes
> > > sense to me in my head--that each side should perform it's own
> > > chicanery.  i'm not saying it can't be made to work some other way.
> > >
> > > -j
> > >
> > > --
> > > "'Nuke the whales?' You don't really believe that, do you?
> > >  I dunno. Gotta nuke something."
> > >         --The Simpsons
> > >
> --
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> 

Re: NAT issues on a VPN tunnel

[Jason Opperisano]

On Fri, Nov 05, 2004 at 08:44:05AM -0800, Chris Lyon wrote:
> I am still trying to get a match rule going but it is saying something about
> libipt_match.so not being loaded. I did try to load it but it can't so I am
> digging around the kernel to find out what the hell is missing.

libipt_*.so are library file for the iptables command, not the kernel.

i am not aware of any file called "libipt_match.so" so i'm not sure what
that error means...but you need to be looking at the iptables side of
things, not the kernel.

are your kernel and userspace out of sync (i.e. you patched your kernel
from POM, and rebuilt the kernel but not the iptables package)?

-j

--
"I'll be deep in the cold, cold ground before I recognize Missoura!"
        --The Simpsons

NAT issues on a VPN tunnel

[Chris Lyon]

So, I am trying to use NAT to solve the problem below because of an IP
addressing conflict issue but I am not having much luck. Basically all of
the Site A needs to get to only a few devices at each site B&C so I am
trying to do PREROUTING NAT on the far end systems. I have the tunnels up
and I can see the traffic getting to the remote side on ipsec0 but I just
can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1. 

Command that I think should work
iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to 10.10.10.10 
iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to 1.1.1.1


Any ideas? Layout and configs are below.


Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
					 \ NAT FROM 1.1.1.1 10.10.1.1
example
					  \--Internet--Site C eth0 -
10.10.0.0/16
						NAT FROM 1.1.2.1 10.10.1.1
example


So here is the openswan configurations for your reference:

Site A

conn site_a-to-site_b
        #---------(local side is left side)
        left=<public site a>
        leftsubnet=192.168.254.0/24
        leftnexthop=%defaultroute
        #---------(remote side is right side)
        right=<public site b>
        rightsubnet=1.1.0.0/16
        #---------Auto Key Stuff
        pfs=yes
        auth=esp
        authby=secret
        esp=3des-md5-96
        keylife=8h
        keyingtries=0


Site B

conn site_b-to-site_a
        #---------(local side is left side)
        left=<public site b>
        leftsubnet=1.1.0.0/16
        leftnexthop=%defaultroute
        #---------(remote side is right side)
        right=<public site a>
        rightsubnet=192.168.254.0/24
        #---------Auto Key Stuff
        pfs=yes
        auth=esp
        authby=secret
        esp=3des-md5-96
        keylife=8h
        keyingtries=0

Re: NAT issues on a VPN tunnel

[John A. Sullivan III]

On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> So, I am trying to use NAT to solve the problem below because of an IP
> addressing conflict issue but I am not having much luck. Basically all of
> the Site A needs to get to only a few devices at each site B&C so I am
> trying to do PREROUTING NAT on the far end systems. I have the tunnels up
> and I can see the traffic getting to the remote side on ipsec0 but I just
> can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1. 
> 
> Command that I think should work
> iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to 10.10.10.10 
> iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to 1.1.1.1
> 
> 
> Any ideas? Layout and configs are below.
> 
> 
> Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
> 					 \ NAT FROM 1.1.1.1 10.10.1.1
> example
> 					  \--Internet--Site C eth0 -
> 10.10.0.0/16
> 						NAT FROM 1.1.2.1 10.10.1.1
> example
> 
> 
> So here is the openswan configurations for your reference:
> 
> Site A
> 
> conn site_a-to-site_b
>         #---------(local side is left side)
>         left=<public site a>
>         leftsubnet=192.168.254.0/24
>         leftnexthop=%defaultroute
>         #---------(remote side is right side)
>         right=<public site b>
>         rightsubnet=1.1.0.0/16
>         #---------Auto Key Stuff
>         pfs=yes
>         auth=esp
>         authby=secret
>         esp=3des-md5-96
>         keylife=8h
>         keyingtries=0
> 
> 
> Site B
> 
> conn site_b-to-site_a
>         #---------(local side is left side)
>         left=<public site b>
>         leftsubnet=1.1.0.0/16
>         leftnexthop=%defaultroute
>         #---------(remote side is right side)
>         right=<public site a>
>         rightsubnet=192.168.254.0/24
>         #---------Auto Key Stuff
>         pfs=yes
>         auth=esp
>         authby=secret
>         esp=3des-md5-96
>         keylife=8h
>         keyingtries=0
This looks terribly familiar.  Is this an old post come back to life or
was it on one of the *swan lists? I thought we left off with some
discussion of where to do the NAT and that the basic set up described
should work but were unsure about how you knew the packets were not
being NATd correctly.  I don't recall a reply after that.  Take care -
John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

RE: NAT issues on a VPN tunnel

[Chris Lyon]

> -----Original Message-----
> From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> Sent: Tuesday, November 02, 2004 8:09 AM
> To: Christopher Lyon
> Cc: Netfilter users list
> Subject: Re: NAT issues on a VPN tunnel
> 
> On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> > So, I am trying to use NAT to solve the problem below because of an IP
> > addressing conflict issue but I am not having much luck. Basically all
> of
> > the Site A needs to get to only a few devices at each site B&C so I am
> > trying to do PREROUTING NAT on the far end systems. I have the tunnels
> up
> > and I can see the traffic getting to the remote side on ipsec0 but I
> just
> > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1.
> >
> > Command that I think should work
> > iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to
> 10.10.10.10
> > iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to
> 1.1.1.1
> >
> >
> > Any ideas? Layout and configs are below.
> >
> >
> > Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
> > 					 \ NAT FROM 1.1.1.1 10.10.1.1
> > example
> > 					  \--Internet--Site C eth0 -
> > 10.10.0.0/16
> > 						NAT FROM 1.1.2.1 10.10.1.1
> > example
> >
> >
> > So here is the openswan configurations for your reference:
> >
> > Site A
> >
> > conn site_a-to-site_b
> >         #---------(local side is left side)
> >         left=<public site a>
> >         leftsubnet=192.168.254.0/24
> >         leftnexthop=%defaultroute
> >         #---------(remote side is right side)
> >         right=<public site b>
> >         rightsubnet=1.1.0.0/16
> >         #---------Auto Key Stuff
> >         pfs=yes
> >         auth=esp
> >         authby=secret
> >         esp=3des-md5-96
> >         keylife=8h
> >         keyingtries=0
> >
> >
> > Site B
> >
> > conn site_b-to-site_a
> >         #---------(local side is left side)
> >         left=<public site b>
> >         leftsubnet=1.1.0.0/16
> >         leftnexthop=%defaultroute
> >         #---------(remote side is right side)
> >         right=<public site a>
> >         rightsubnet=192.168.254.0/24
> >         #---------Auto Key Stuff
> >         pfs=yes
> >         auth=esp
> >         authby=secret
> >         esp=3des-md5-96
> >         keylife=8h
> >         keyingtries=0
> This looks terribly familiar.  Is this an old post come back to life or
> was it on one of the *swan lists? I thought we left off with some
> discussion of where to do the NAT and that the basic set up described
> should work but were unsure about how you knew the packets were not
> being NATd correctly.  I don't recall a reply after that.  Take care -
> John

Hello John,

It was actually on the openswan list and since this is more of an iptables,
nat question I moved the post to here.

Yes, I did reply and I am still trying to get this working. I have tried a
bunch of combinations and have yet to find the answer.


> --
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> ---
> If you are interested in helping to develop a GPL enterprise class
> VPN/Firewall/Security device management console, please visit
> http://iscs.sourceforge.net
> 

RE: NAT issues on a VPN tunnel

[John A. Sullivan III]

On Tue, 2004-11-02 at 12:02, Chris Lyon wrote:
> > -----Original Message-----
> > From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> > Sent: Tuesday, November 02, 2004 8:09 AM
> > To: Christopher Lyon
> > Cc: Netfilter users list
> > Subject: Re: NAT issues on a VPN tunnel
> > 
> > On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> > > So, I am trying to use NAT to solve the problem below because of an IP
> > > addressing conflict issue but I am not having much luck. Basically all
> > of
> > > the Site A needs to get to only a few devices at each site B&C so I am
> > > trying to do PREROUTING NAT on the far end systems. I have the tunnels
> > up
> > > and I can see the traffic getting to the remote side on ipsec0 but I
> > just
> > > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1.
> > >
> > > Command that I think should work
> > > iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to
> > 10.10.10.10
> > > iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to
> > 1.1.1.1
> > >
> > >
> > > Any ideas? Layout and configs are below.
> > >
> > >
> > > Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
> > > 					 \ NAT FROM 1.1.1.1 10.10.1.1
> > > example
> > > 					  \--Internet--Site C eth0 -
> > > 10.10.0.0/16
> > > 						NAT FROM 1.1.2.1 10.10.1.1
> > > example
> > >
> > >
> > > So here is the openswan configurations for your reference:
> > >
> > > Site A
> > >
> > > conn site_a-to-site_b
> > >         #---------(local side is left side)
> > >         left=<public site a>
> > >         leftsubnet=192.168.254.0/24
> > >         leftnexthop=%defaultroute
> > >         #---------(remote side is right side)
> > >         right=<public site b>
> > >         rightsubnet=1.1.0.0/16
> > >         #---------Auto Key Stuff
> > >         pfs=yes
> > >         auth=esp
> > >         authby=secret
> > >         esp=3des-md5-96
> > >         keylife=8h
> > >         keyingtries=0
> > >
> > >
> > > Site B
> > >
> > > conn site_b-to-site_a
> > >         #---------(local side is left side)
> > >         left=<public site b>
> > >         leftsubnet=1.1.0.0/16
> > >         leftnexthop=%defaultroute
> > >         #---------(remote side is right side)
> > >         right=<public site a>
> > >         rightsubnet=192.168.254.0/24
> > >         #---------Auto Key Stuff
> > >         pfs=yes
> > >         auth=esp
> > >         authby=secret
> > >         esp=3des-md5-96
> > >         keylife=8h
> > >         keyingtries=0
> > This looks terribly familiar.  Is this an old post come back to life or
> > was it on one of the *swan lists? I thought we left off with some
> > discussion of where to do the NAT and that the basic set up described
> > should work but were unsure about how you knew the packets were not
> > being NATd correctly.  I don't recall a reply after that.  Take care -
> > John
> 
> Hello John,
> 
> It was actually on the openswan list and since this is more of an iptables,
> nat question I moved the post to here.
> 
> Yes, I did reply and I am still trying to get this working. I have tried a
> bunch of combinations and have yet to find the answer.
> 
<snip>
Ah, that's where I saw it.  I must have missed the response.  You said,
"I can see the traffic getting to the remote side on ipsec0 but I
> just
> > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1."

How are you seeing this? If you place a log rule, do you see the packet
in the nat table PREROUTING chain on ipsec0? Just for kicks, what kernel
version are you running? Take care - John

-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

RE: NAT issues on a VPN tunnel

[Chris Lyon]

> -----Original Message-----
> From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> Sent: Tuesday, November 02, 2004 10:50 AM
> To: Christopher Lyon
> Cc: Netfilter users list
> Subject: RE: NAT issues on a VPN tunnel
> 
> On Tue, 2004-11-02 at 12:02, Chris Lyon wrote:
> > > -----Original Message-----
> > > From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> > > Sent: Tuesday, November 02, 2004 8:09 AM
> > > To: Christopher Lyon
> > > Cc: Netfilter users list
> > > Subject: Re: NAT issues on a VPN tunnel
> > >
> > > On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> > > > So, I am trying to use NAT to solve the problem below because of an
> IP
> > > > addressing conflict issue but I am not having much luck. Basically
> all
> > > of
> > > > the Site A needs to get to only a few devices at each site B&C so I
> am
> > > > trying to do PREROUTING NAT on the far end systems. I have the
> tunnels
> > > up
> > > > and I can see the traffic getting to the remote side on ipsec0 but I
> > > just
> > > > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1.
> > > >
> > > > Command that I think should work
> > > > iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to
> > > 10.10.10.10
> > > > iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to
> > > 1.1.1.1
> > > >
> > > >
> > > > Any ideas? Layout and configs are below.
> > > >
> > > >
> > > > Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
> > > > 					 \ NAT FROM 1.1.1.1
10.10.1.1
> > > > example
> > > > 					  \--Internet--Site C eth0 -
> > > > 10.10.0.0/16
> > > > 						NAT FROM 1.1.2.1
10.10.1.1
> > > > example
> > > >
> > > >
> > > > So here is the openswan configurations for your reference:
> > > >
> > > > Site A
> > > >
> > > > conn site_a-to-site_b
> > > >         #---------(local side is left side)
> > > >         left=<public site a>
> > > >         leftsubnet=192.168.254.0/24
> > > >         leftnexthop=%defaultroute
> > > >         #---------(remote side is right side)
> > > >         right=<public site b>
> > > >         rightsubnet=1.1.0.0/16
> > > >         #---------Auto Key Stuff
> > > >         pfs=yes
> > > >         auth=esp
> > > >         authby=secret
> > > >         esp=3des-md5-96
> > > >         keylife=8h
> > > >         keyingtries=0
> > > >
> > > >
> > > > Site B
> > > >
> > > > conn site_b-to-site_a
> > > >         #---------(local side is left side)
> > > >         left=<public site b>
> > > >         leftsubnet=1.1.0.0/16
> > > >         leftnexthop=%defaultroute
> > > >         #---------(remote side is right side)
> > > >         right=<public site a>
> > > >         rightsubnet=192.168.254.0/24
> > > >         #---------Auto Key Stuff
> > > >         pfs=yes
> > > >         auth=esp
> > > >         authby=secret
> > > >         esp=3des-md5-96
> > > >         keylife=8h
> > > >         keyingtries=0
> > > This looks terribly familiar.  Is this an old post come back to life
> or
> > > was it on one of the *swan lists? I thought we left off with some
> > > discussion of where to do the NAT and that the basic set up described
> > > should work but were unsure about how you knew the packets were not
> > > being NATd correctly.  I don't recall a reply after that.  Take care -
> > > John
> >
> > Hello John,
> >
> > It was actually on the openswan list and since this is more of an
> iptables,
> > nat question I moved the post to here.
> >
> > Yes, I did reply and I am still trying to get this working. I have tried
> a
> > bunch of combinations and have yet to find the answer.
> >
> <snip>
> Ah, that's where I saw it.  I must have missed the response.  You said,
> "I can see the traffic getting to the remote side on ipsec0 but I
> > just
> > > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1."
> 
> How are you seeing this? If you place a log rule, do you see the packet
> in the nat table PREROUTING chain on ipsec0? Just for kicks, what kernel
> version are you running? Take care - John

I am using tethereal to see the ssh and ping requests come across the
tunnel. 

Kernel - 2.4.26 or 2.4.26-gentoo-r9

> 
> --
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> ---
> If you are interested in helping to develop a GPL enterprise class
> VPN/Firewall/Security device management console, please visit
> http://iscs.sourceforge.net
> 

RE: NAT issues on a VPN tunnel

[John A. Sullivan III]

On Tue, 2004-11-02 at 15:05, Chris Lyon wrote:
> > -----Original Message-----
> > From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> > Sent: Tuesday, November 02, 2004 10:50 AM
> > To: Christopher Lyon
> > Cc: Netfilter users list
> > Subject: RE: NAT issues on a VPN tunnel
> > 
> > On Tue, 2004-11-02 at 12:02, Chris Lyon wrote:
> > > > -----Original Message-----
> > > > From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com]
> > > > Sent: Tuesday, November 02, 2004 8:09 AM
> > > > To: Christopher Lyon
> > > > Cc: Netfilter users list
> > > > Subject: Re: NAT issues on a VPN tunnel
> > > >
> > > > On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> > > > > So, I am trying to use NAT to solve the problem below because of an
> > IP
> > > > > addressing conflict issue but I am not having much luck. Basically
> > all
> > > > of
> > > > > the Site A needs to get to only a few devices at each site B&C so I
> > am
> > > > > trying to do PREROUTING NAT on the far end systems. I have the
> > tunnels
> > > > up
> > > > > and I can see the traffic getting to the remote side on ipsec0 but I
> > > > just
> > > > > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1.
> > > > >
> > > > > Command that I think should work
> > > > > iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to
> > > > 10.10.10.10
> > > > > iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to
> > > > 1.1.1.1
> > > > >
> > > > >
> > > > > Any ideas? Layout and configs are below.
> > > > >
> > > > >
> > > > > Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
> > > > > 					 \ NAT FROM 1.1.1.1
> 10.10.1.1
> > > > > example
> > > > > 					  \--Internet--Site C eth0 -
> > > > > 10.10.0.0/16
> > > > > 						NAT FROM 1.1.2.1
> 10.10.1.1
> > > > > example
> > > > >
> > > > >
> > > > > So here is the openswan configurations for your reference:
> > > > >
> > > > > Site A
> > > > >
> > > > > conn site_a-to-site_b
> > > > >         #---------(local side is left side)
> > > > >         left=<public site a>
> > > > >         leftsubnet=192.168.254.0/24
> > > > >         leftnexthop=%defaultroute
> > > > >         #---------(remote side is right side)
> > > > >         right=<public site b>
> > > > >         rightsubnet=1.1.0.0/16
> > > > >         #---------Auto Key Stuff
> > > > >         pfs=yes
> > > > >         auth=esp
> > > > >         authby=secret
> > > > >         esp=3des-md5-96
> > > > >         keylife=8h
> > > > >         keyingtries=0
> > > > >
> > > > >
> > > > > Site B
> > > > >
> > > > > conn site_b-to-site_a
> > > > >         #---------(local side is left side)
> > > > >         left=<public site b>
> > > > >         leftsubnet=1.1.0.0/16
> > > > >         leftnexthop=%defaultroute
> > > > >         #---------(remote side is right side)
> > > > >         right=<public site a>
> > > > >         rightsubnet=192.168.254.0/24
> > > > >         #---------Auto Key Stuff
> > > > >         pfs=yes
> > > > >         auth=esp
> > > > >         authby=secret
> > > > >         esp=3des-md5-96
> > > > >         keylife=8h
> > > > >         keyingtries=0
> > > > This looks terribly familiar.  Is this an old post come back to life
> > or
> > > > was it on one of the *swan lists? I thought we left off with some
> > > > discussion of where to do the NAT and that the basic set up described
> > > > should work but were unsure about how you knew the packets were not
> > > > being NATd correctly.  I don't recall a reply after that.  Take care -
> > > > John
> > >
> > > Hello John,
> > >
> > > It was actually on the openswan list and since this is more of an
> > iptables,
> > > nat question I moved the post to here.
> > >
> > > Yes, I did reply and I am still trying to get this working. I have tried
> > a
> > > bunch of combinations and have yet to find the answer.
> > >
> > <snip>
> > Ah, that's where I saw it.  I must have missed the response.  You said,
> > "I can see the traffic getting to the remote side on ipsec0 but I
> > > just
> > > > can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1."
> > 
> > How are you seeing this? If you place a log rule, do you see the packet
> > in the nat table PREROUTING chain on ipsec0? Just for kicks, what kernel
> > version are you running? Take care - John
> 
> I am using tethereal to see the ssh and ping requests come across the
> tunnel. 
> 
> Kernel - 2.4.26 or 2.4.26-gentoo-r9
<snip>
So what do you see in tethereal? I would suggest that you place a log
rule with a match identical to your NAT rule in front of the rule which
you expect will perform the NAT and see if the packet ever makes it to
that NAT rule.  If you do not see the packet matched by the log rule,
either the match is wrong or your have an upstream problem.  You could
then put a more general match log rule in place to see what the packets
which you are receiving do look like.  In other words, see if you can
narrow down exactly where the process is not behaving as expected rather
than just looking at the packets going in and out of the interface. 
Hope this helps - John  
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Re: NAT issues on a VPN tunnel

[Jason Opperisano]

On Tue, 2004-11-02 at 10:40, Chris Lyon wrote:
> So, I am trying to use NAT to solve the problem below because of an IP
> addressing conflict issue but I am not having much luck. Basically all of
> the Site A needs to get to only a few devices at each site B&C so I am
> trying to do PREROUTING NAT on the far end systems. 

try doing it with POSTROUTING on the local system (site a).

-j

--
"I bent my wookie."
	--The Simpsons

Re: NAT issues on a VPN tunnel

[Michael Gale]

Hello,

	Before you start adding in customer NAT rules are you sure that end 
point to end point work ?

If the VPN device is setup on the gw box or the router has a route of 
the network on the other side of the VPN you will not need to NAT any 
traffic.

We have a VPN device plugged into a production network at a IDC, the 
default gw is the firewall, not the VPN device and we did not want to 
add a static route on the firewall. So on the VPN device, we SNAT all 
packets that leave that machine to it's local IP. That way all 
connections that come in from the VPN look like they came from the VPN 
device.

Michael.



Chris Lyon wrote:
> So, I am trying to use NAT to solve the problem below because of an IP
> addressing conflict issue but I am not having much luck. Basically all of
> the Site A needs to get to only a few devices at each site B&C so I am
> trying to do PREROUTING NAT on the far end systems. I have the tunnels up
> and I can see the traffic getting to the remote side on ipsec0 but I just
> can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1. 
> 
> Command that I think should work
> iptables -t nat -A PREROUTING -i ipsec0 -d 1.1.1.1 -j DNAT --to 10.10.10.10 
> iptables -t nat -A POSTROUTING -o ipsec0 -s 10.10.10.10 -j SNAT --to 1.1.1.1
> 
> 
> Any ideas? Layout and configs are below.
> 
> 
> Site A eth0 - 192.168.254.0/24--Internet--Site B eth0 - 10.10.0.0/16
> 					 \ NAT FROM 1.1.1.1 10.10.1.1
> example
> 					  \--Internet--Site C eth0 -
> 10.10.0.0/16
> 						NAT FROM 1.1.2.1 10.10.1.1
> example
> 
> 
> So here is the openswan configurations for your reference:
> 
> Site A
> 
> conn site_a-to-site_b
>         #---------(local side is left side)
>         left=<public site a>
>         leftsubnet=192.168.254.0/24
>         leftnexthop=%defaultroute
>         #---------(remote side is right side)
>         right=<public site b>
>         rightsubnet=1.1.0.0/16
>         #---------Auto Key Stuff
>         pfs=yes
>         auth=esp
>         authby=secret
>         esp=3des-md5-96
>         keylife=8h
>         keyingtries=0
> 
> 
> Site B
> 
> conn site_b-to-site_a
>         #---------(local side is left side)
>         left=<public site b>
>         leftsubnet=1.1.0.0/16
>         leftnexthop=%defaultroute
>         #---------(remote side is right side)
>         right=<public site a>
>         rightsubnet=192.168.254.0/24
>         #---------Auto Key Stuff
>         pfs=yes
>         auth=esp
>         authby=secret
>         esp=3des-md5-96
>         keylife=8h
>         keyingtries=0
> 
> 
> 
> 
> 
> 
> 

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

We Pledge Allegiance to the Penguin