On Fri, 2 Feb 2001, Sandra Hernandez Marsa wrote:
> We're deploying a VPN in order to interconnect to sites of a given
> company using Linux, IPChains and FreeSwan. Currently both sites are
> using private 192.168.7.0/25 IP's.
> A) Since IP's at both subnets are private do we need to use
> Masquerading at GW1 and GW2 in order to route paquets through the VPN
> or does IPSec encapsulation provide for this already?
i haven't used your combo, but i have used OpenBSD/ipf/ipsec (using manual
keying) in a NAT environment. setting up the flows to pass an RFC1918
address to the destination network allowed for the encapsulation of, in
your case, a 192.168.7/24 packet in a real, Internet routable packet.
as such, i haven't had a problem. provided both sides are 'in the know
about the flow' of the IPs for their IPsec (ie route these addresses, your
192.168.7/24, through the encapsulating interface with these parameters),
all should be well.
> B) We have been sniffing the packets sent from GW1 to GW2 through the
> ipsec0 interface and we've seen that the destination IP is a private
> IP from Site B! How can this be? If that's going on to the Internet it
> won't get routed... or could it be that tcpdump is interpreting IPSec?
no TCPdump that i have used has ever interpreted the IPsec traffic without
explicitely forcing it to know about the keys and decoding using the
appropriate algorithms. it just puts the type as "esp" when appropriate.
all that should be visible in the packets on the external wire is a real
IP address in the header and a protocl version appropriate for IPsec, ie
esp (IP proto 50).
i hope this makes sense. like i said i haven't used your combo, but ...
IPsec should be very similar, independent of the implementation. it is,
after all, a standard.
____________________________
jose nazario [EMAIL PROTECTED]
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
