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 "firewall"only 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
