> Thank you for your suggestions. Things are not changed much after > I did the following as you advised: > > - As per Lynn's remark, I now use only one /etc/ipsec.conf on > both sides. The FreeSWAN doc said that you may need to change > the line "interfaces=", but they are identical in this case > too, i.e. both use eth0. > So only the ipsec.secrets are different.
The previous configuration files you had looked fine...the left & right portions on each end don't have to match, as long as each end can figure out whether it's supposed to be "left" or "right" as defined by it's own local configruation file. It's perfectly OK to have both sides think they're "left", and the other end is "right", or vise-versa... > - The ping I did was done on an internal machine behind the firewall, > 192.168.9.204, not on the gateway (192.168.9.254). From there > I tried to ping 192.168.1.202, another machine behind the > remote gateway. Good...this is how you are supposed to test. > - I removed "ip_masq_ipsec" from /etc/modules. I also set > eth0_IP_SPOOF=NO in /etc/network.conf This is good as well... > - I saw some suspicious variables in /etc/network.conf but > not sure if they affect anything in my case: > > # Accept ICMP Redirects on ALL interfaces, also depends on /proc > # per interface IP forwarding flag. - YES/NO > ALLIF_ACCEPT_REDIRECTS=NO > ... > # Need these both for interfaces run by daemons - ie PPP, CIPE, some > # WAN interfaces > # IP spoofing protection by default for interfaces - YES/NO > DEF_IP_SPOOF=YES > ... > eth1_IPADDR=192.168.1.254 > eth1_MASKLEN=24 > eth1_BROADCAST=192.168.1.255 > eth1_IP_SPOOF=YES > ... All this looks OK, and shouldn't affect your IPSec link on eth0. > - After pinging, I saw nothing particular in /var/log/auth.log > nor in /var/log/messages on both sides. > > - I think I have protocol 50, 51 and UDP port 500 set in > /etc/network.conf, but for sure I list the partial output from > net ipfilter list. You may see something wrong I have here. It looks like you do have the required IPSec firewall rules in place: > Extern IP: 24.83.28.213 > Chain input (policy DENY: 3 packets, 734 bytes): > pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports > 11940 2123K ACCEPT udp ------ 0xFF 0x00 eth0 0.0.0.0/0 0.0.0.0/0 * -> 500 > 0 0 ACCEPT 50 ------ 0xFF 0x00 eth0 0.0.0.0/0 24.83.28.213 n/a > 0 0 ACCEPT 51 ------ 0xFF 0x00 eth0 0.0.0.0/0 24.83.28.213 n/a Based on everything you've reported so-far, I would either suspect firewall rules on the remote gateway (you only listed one side, so there could be problems with the other end), or someone filtering IPSec traffic between your two boxes. *MANY* ISP's are beginning to filter IPSec traffic for folks who don't pay "business" class rates...it's easy to do, and usually prompts most actual businesses to spend 2-3 times more for services. You might want to check with local user groups, and/or any online forums discussing your particular ISP(s), and see if they might be dropping your IPSec traffic. The symptoms you're reporting are very consistent with protocol 50 traffic not making it through the network between your two VPN boxes. I don't know of an easy way to test for this...with the two LEAF boxes at either end, probabaly the easiest thing to do is run the following commands on *BOTH* VPN gateway's: ipchains -I input -p 50 -l ipchains -I output -p 50 -l This will cause *ALL* ESP (protocol 50) packets to get logged when entering and leaving your firewall. If you see packets getting sent from one mahcine, but not being recieved by the other end, you'll know something is wrong, probably the ISP at one end or the other filtering the traffic... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
