[VPN] Re: fw1 site to site vpn subnet conflict

Travis Watson travis at traviswatson.com
Mon Sep 4 14:37:15 EDT 2006


Zoe,

I think you would be best off with a pool NAT.  If both sides are 
192.168.x, you can make a network object for something in 10.x or 
172.16.x, or whatever, and have the route for that netblock to point to 
the internal core router, which will take care of the rest of the 
routing logic from there.  It's been years since I've worked with a 
Chokepoint, but I believe that you put the netblock in the encrypt rule 
itself (and make sure it is part of the encryption domain and 
anti-spoofing group so you don't get anti-spoofing errors).  This way 
you don't have to worry about making NAT rules and it gives you room for 
growth if/when this situation comes up again.  You *may* have to play 
with the SA's on both sides, but I don't think so (CP has their own 
proprietary way of dealing with SA's, but it's pretty close to everyone 
else).  Pity you don't have Netscreens--they have a much more elegant 
solution to the problem you're facing.  But CP can handle it, I believe.

--Travis

zoe wrote:

>I can't change the subnets at either end and I can't change the IP's on any
>of the servers. When I access hosts on their subnet I can use the real
>addresses of their hosts because I'm not using the subnet that these hosts
>are on in my network.
>
>
>Example scenario
>
>- My network = 192.168.100.0. I apply a rule that NAT's this behind
>192.168.98.0 for connections to client
>- Hosts on client network that I need to access are in the 192.168.99.0 I'm
>not using this range at all so hosts on my network can use the real
>addresses to get to servers on client network
>- Client needs to get to some of my servers. His clients can't use the real
>addresses of my servers because they will be routed off to the 192.168.100
>subnet on their network.
>- To overcome this I tried setting up a static nat rule like the one below
>for one of the hosts that they are trying to access. 
>E.g  original packet = src=client_encryption_domain dest=192.168.98.10 
>     translated packet = destination=192.168.100.10
>     original packet = src=192.168.100.10 dest=client_encryption_domain 
>     translated packet = source=192.168.100.10
>
>I initially got errors (dropped packet forwarded between two interfaces)
>until I set up a static route on the firewall (e.g 192.168.98.10
>255.255.255.255 gw 192.168.100.10)
>After this I did see the encypted traffic coming through when they tried to
>access the host using the nat address (192.168.98.10) but they didn't get
>any response from the machine and I couldn't see any return traffic. 
>
>Cheers
>
>Zoe
>
>
>-----Original Message-----
>From: Smith, Duane [mailto:Duane.Smith at nasa.gov] 
>Sent: 31 August 2006 23:02
>To: Ken Livingston; zmmay at hotmail.com; vpn at lists.shmoo.com
>Subject: RE: [VPN] Re: fw1 site to site vpn subnet conflict
>
>We have a similar configuration involving a datacenter that wanted us to
>interface with servers in a 10.x network. I don't see why you can't use the
>nat'ing solution in both directions. They set the nat'ing rule up on their
>end and we connect to them just fine. They had to add an IP address from a
>different 10.y subnet to a few of their servers and nat the 10.y so that the
>nat rule would not apply to other integrations where the 10.x was already in
>production. In short: why is you nat rule "directional"?
>
>drs
>
>-----Original Message-----
>From: vpn-bounces+duane.smith=msfc.nasa.gov at lists.shmoo.com
>[mailto:vpn-bounces+duane.smith=msfc.nasa.gov at lists.shmoo.com] On Behalf Of
>Ken Livingston
>Sent: Thursday, August 31, 2006 8:32 AM
>To: vpn at lists.shmoo.com
>Subject: [VPN] Re: fw1 site to site vpn subnet conflict
>
>I take it that it would be too much to change either your private network
>subnet or the subnet on the other end which conflicts with yours?  I think
>that's going to be the only thing you can do in this case.  If the
>individual devices on the remote end don't need access to the rest of their
>network, you can try changing their default gateway to the IP address of the
>VPN endpoint on the remote side and that should allow their traffic to pass
>through the VPN correctly, but they won't be able to access the other
>network subnets on their own side.
>
>Maybe someone else have other ideas but I think you'll have to change one
>side or the other in order to make this work properly.
>
>Undrhil
>
>----- Original Message -----
>From: "zoe" <zmmay at hotmail.com>
>To: <vpn at lists.shmoo.com>
>Sent: Wednesday, August 30, 2006 11:30 AM
>Subject: [VPN] fw1 site to site vpn subnet conflict
>
>
>  
>
>>Hi
>>
>>I have a site to site vpn with a client (fw1 at each end). I only have
>>    
>>
>one
>  
>
>>private subnet behind my firewall but my client has many and one of 
>>these conflicts with mine.
>>Initially I only needed this connection to work one way (us --> them)
>>    
>>
>so
>I
>  
>
>>put a manual nat rule in place which hide nats my /24 behind a 
>>different private /24 for connections to the client. This works fine
>>
>>Now I have been asked to enable inbound traffic to certain hosts from
>>    
>>
>the
>  
>
>>client (them --> us). They can't use the real addresses of my hosts as 
>>they would be routed to their own network. Any suggestions on
>>    
>>
>how
>  
>
>>this can be done (if at all)? I have tried a few things including
>>    
>>
>adding
>  
>
>>static nat inbound to the few hosts they need to access but have had
>>    
>>
>no
>  
>
>>success. I can post more config if anyone thinks they can help
>>
>>Thanks
>>
>>Zoe
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>------------------------------------------------------------------------
>---
>-----
>
>
>  
>
>>_______________________________________________
>>VPN mailing list
>>VPN at lists.shmoo.com
>>http://lists.shmoo.com/mailman/listinfo/vpn
>>    
>>
>
>_______________________________________________
>VPN mailing list
>VPN at lists.shmoo.com
>http://lists.shmoo.com/mailman/listinfo/vpn
>
>_______________________________________________
>VPN mailing list
>VPN at lists.shmoo.com
>http://lists.shmoo.com/mailman/listinfo/vpn
>
>  
>




More information about the VPN mailing list