Re: Site-to-Site VPN with overlapping RFC1918 addresses
Won't that be an issue for the firewall? It would RDR the packet in order to change the destination address to 192.168.x.x (for a packet destined for the tunnel), but the firewall also has routes to the internal network for those addresses. I would think that it wouldn't be able to differentiate between the 192.168.x.x hosts on the local network, and the 192.168.x.x hosts on the remote network (through the tunnel). Adding the second host effectively isolates the networks (i.e. PF box A firewallonly has routes to local 192.168.x.x hosts, and PF box B gateway only has routes to remote 192.168.x.x hosts - through the tunnel). NAT/RDR modifies the addresses such that neither box sees a 192.168.x.x address unless it's for a host that it knows a route to... - Original Message From: Karl O. Pinc [EMAIL PROTECTED] To: Steve Chinatti [EMAIL PROTECTED] Cc: pf@benzedrine.cx Sent: Friday, August 18, 2006 2:58:39 PM Subject: Re: Site-to-Site VPN with overlapping RFC1918 addresses On 08/18/2006 10:24:29 AM, Steve Chinatti wrote: Hello PF List, I'm hoping someone can help me out with my configuration issue. The problem is that there is overlap in the private RFC1918 addresses used in both sites. Let's call them SiteA and SiteB. I only need to connect from SiteA-SiteB (i.e. connections will never be initiated from SiteB-SiteA, but of course sessions initiated from SiteA will have return traffic...). SiteA (my site) is using a OpenBSD PF firewall with multiple interfaces (internal, external, DMZ). The DMZ uses a non-conflicting address (not in the 192.168.0.0/16 range), but the internal hosts use the 192.168.0.0/16 network. Couldn't you NAT on your external interface and then rdr the result to the PIX and have that route the traffic through the tunnel? Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Site-to-Site VPN with overlapping RFC1918 addresses
On 08/21/2006 02:04:02 PM, Steve Chinatti wrote: Won't that be an issue for the firewall? It would RDR the packet in order to change the destination address to 192.168.x.x (for a packet destined for the tunnel), but the firewall also has routes to the internal network for those addresses. I think my thoughts were not fully developed. I'm a little hazy on the addressing you're currently using and which device is doing what I think the flaw in my scheme is the RDR, which will mess with the destination IP and so make it impossible to get the packet where it ultimately needs to go. My first thought was to use a route-to, which wouldn't have such a flaw, but I saw that NAT didn't have a route-to option so I tried a RDR but that's wrong. Maybe a separate pass firewall rule with route-to will do the trick? My understanding of route-to is that it'll get the packet delivered to the right MAC address on an attached LAN without messing with the packet contents. If this is right then so long as the external address on your firewall is globally unique (or you make an alias you NAT to that is) then this _should_ work. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Site-to-Site VPN with overlapping RFC1918 addresses
On 08/18/2006 10:24:29 AM, Steve Chinatti wrote: Hello PF List, I'm hoping someone can help me out with my configuration issue. The problem is that there is overlap in the private RFC1918 addresses used in both sites. Let's call them SiteA and SiteB. I only need to connect from SiteA-SiteB (i.e. connections will never be initiated from SiteB-SiteA, but of course sessions initiated from SiteA will have return traffic...). SiteA (my site) is using a OpenBSD PF firewall with multiple interfaces (internal, external, DMZ). The DMZ uses a non-conflicting address (not in the 192.168.0.0/16 range), but the internal hosts use the 192.168.0.0/16 network. Couldn't you NAT on your external interface and then rdr the result to the PIX and have that route the traffic through the tunnel? Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
