-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 13 August 2003 13:30, Smokin Joe Fission wrote:
> Hopefully someone will be able to help out with my particular
> configuration.
>
> I have a firewall running Linux RHS 9 and iptables with two physical
> interfaces and superfreeswan 1.99. One is external, the other is a
> private network that is NATted through the firewall.
>
> Behind the firewall, I have 3 machines: a web server, a database server
> and an adminstrative server, all with superfreeswan 1.99 as well. As
> these machines are going to be in a co-location facility, I have opted
> to use host-to-host encryption to prevent anyone from eavesdropping on
> traffic between the machines. I have all the tunnels up and running fine
> on the internal network, and all the machines can ping each other and
> access servers through the vpn tunnels no problem. I have also confirmed
> that the traffic on the internal network is all encrypted by sniffing it
> with my laptop.
>
> Unfortunately, as soon as I try to access anything outside the internal
> network through the firewall, nothing happens.
This wasn't clear from your e-mail: do you have a tunnels between the various
servers and the firewall as well? (You've got an internal ipsec interface
listed in your diagram, so I think you do.)
Going on that assumption, envision a ping from your webserver to an outside
host (say, www.google.com). The packets travel between the webserver and the
gateway, in the clear, and the gateway forwards the packet. None of these
steps result in the IPsec machinery stepping in. However, the firewall runs
into trouble when it attempts to forward the response packets back to your
web server - you've got a kernel route with your web server's IP address via
ipsec0. The packet gets shunted into the KLIPS machinery.
If you had klipsdebugging turned to all, you'd see something like this:
Aug 13 15:14:53 owl kernel: klips_debug:ipsec_findroute:
216.109.127.60(outside host IP)->66.22.13.44(web server internal IP)
Aug 13 15:14:53 owl kernel: klips_debug:rj_match: * See if we match exactly as
a host destination
Aug 13 15:14:53 owl kernel: klips_debug:rj_match: ** try to match a leaf,
t=0pd133c3cc90
*snip*
Aug 13 15:14:53 owl kernel: klips_debug:rj_match: ***** not found.
*snip*
Aug 13 15:14:53 owl kernel: klips_debug:ipsec_tunnel_start_xmit: shunt SA of
DROP or no eroute: dropping.
Since the firewall cannot find an eroute matching the response packet's src IP
and your webserver's dst IP, KLIPS drops the packet. (This is the default
action, defined by the packetdefault parameter in 1.99's ipsec.conf.)
How do you address this? If it's your intent for all the traffic from outside
hosts to use the tunnel when they query your servers - probably a good idea,
as it's unlikely that requests from outside hosts could exceed your
hardware's abilities - then you need to explicitly allow all the traffic from
outside hosts to use the tunnel:
left=gw.internal.ip.address
leftsubnet=0.0.0.0/0
...
The response packet will find a matching eroute. Note that all,
non-local-subnet traffic from the webserver will also be encrypted.
I hope my initial assumption was correct, else this has been a long
explanation fer nuttin'. ;)
- --
Sam Sgro
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBPzqTP0OSC4btEQUtAQF4CgQAqenhaveY4A/IHcxhbqBihKG9K3RZ5wnt
Yr2fwGsklGpa+Ez4rRgPU91XK6oSGa5XyZAXj/0QUyuRpwtOm4s6narVd1eiuanf
uYlGbDAjlvmOPbJquNmC2WXV3TvVbDSH5FpvMZmP/JQLeKfVXBhoyx5ATzCTJF4q
bsbY1KDSRks=
=kUNA
-----END PGP SIGNATURE-----
_______________________________________________
FreeS/WAN Users mailing list
[EMAIL PROTECTED]
https://mj2.freeswan.org/cgi-bin/mj_wwwusr
