I have RedHat 7.2 and I've setup a firewall using IPTABLES to do masq to my ISP. Everything works fine except when I setup a IPSEC VPN connection from inside to an outside VPN server. The connection initially works fine for several minutes and then stop working. In fact, I can't even ping the IPSEC VPN server from the inside network. If I close the connection and re-establish it works fine for another couple of minutes.

Here is my IPTABLES setup.

$IPTABLES -A INPUT -i $INTIF -j ACCEPT
$IPTABLES -A OUTPUT -o $INTIF -j ACCEPT
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

Is there a timeout for MASQ with IPTABLES or is there something being re-negotiated within IPSEC and IPTABLES is not allowing it in?

Any help or pointers would be greatly appreciated.

Thanks.

Ok haven't seen this before but you should try searching freeswans site and redhat's docs for the following problems.

I'm guessing it's one of these.

Timeout problem for masq table entries for ISAKMP UDP packets on the Kernel. "look for a patch this is an old problem on 2.0 Kernels"

What does that mean:
The masq table entries for the ISAKMP UDP traffic times out fairly quickly (relative to the data channel) and is removed.
The remote IPsec host then decided to initiate rekeying before the local IPsec host did, the inbound ISAKMP traffic for the rekey couldn't be routed to the masqueraded host.
The rekey traffic is discarded, the remote IPsec host would think the link had failed, and the connection would then be terminated.

or

Verify that your IPsec Masq Table Lifetime parameter is configured to be the same as or slightly longer than your rekey interval.

/Raz

Thanks for the Feedback. I've put a sniffer on the outside of the F/W to see what is going on. Sure enough, you are correct about the flushing of the connection and the re-keying of ISAKMP. The F/W simply ignores future ISAKMP messages after the connection is flushed.

I'm trying to add a rule with the DNAT Target so that any incoming ISAKMP (ie re-keying) gets its destaddr re-written to the inside VPN client. But no luck. Any advice?

I take it to change the Table Lifetime parameter I need to recompile the iptable_nat module. Do you know of any FAQs that describe this procedure? Being the newbie that I am, I've never done this before.

I wouldn't try to use DNAT to do it as I'm sure a module would be need to redirect it due to the dynamic source port from the first ISAKMP session.

What VPN software you using ? Freeswans ?

Don't think there is anyway without recompiling the Kernel to fix this:

* IP: IPsec masq table lifetime (minutes)
- See your network administrator to determine what the
"rekey interval" or "key lifetime" is set to. The default
lifetime of masq table entries is thirty minutes. If
your rekey interval is greater than thirty minutes,
then you should increase the lifetime to a value
slightly greater than the rekey interval.

Before you do this check if you can't change the rekey interval of the VPN server. "set it to less then 30 min's"

Sorry don't know of a FAQ that's going to help with this.
Best bet is to look through all the documentation on the VPN side as I'm sure this is a common problem.

/Raz

Thank you for the info.

According to the sniffer output, the SRC and DST port for ISAKMP appears to be always 500. I've also seen mentions of this in some of the HOW-TOs.

I don't know what the 30 minute quoted lifetime refers to. I've checked the rekeying interval using the sniffer and its about 3 minutes. So I decided the investigate these timeouts a little further.

I have a virgin 7.4 install (2.4.7-10 Kernel) no builds or any patches.

I'm assuming that the ip_conntrack table is how you monitor the connection. If this is not correct please advise how to do it.

I checked the times displayed in the /proc/net/ip_conntrack table and these are the maximum times I see. I've rounded to the highest minute value.

UDP - 180 sec (3 min)
IP Prot 50 (ESP) - 600 (10 minutes)
TCP SYN - 120 (2 Minutes)
TCP EST - 43200 (120 Hours!!)
TCP TIME_WAIT - 120 sec.
TCP CLOSED - 60 sec.

After the times above the entry(s) is flushed from the ip_conntrack table. Obviously I cannot check the TCP EST state as it usually moves into the CLOSE state before 120 hours.

Its interesting that even after the TCP connection is closed it still keeps the entry in the table for 60 seconds.

I am going to follow your advise and rebuild the kernal and check and change the above times. Maybe I'll manually enter 30 minutes and check the timeouts again.

I've rebuild the kernel and there is no lifetime parameter present when I do a "make menuconfig" or "make config".

Could this be present in older kernels. I'm running 2.4.7-10.

How do you specifically change the lifetime parameter as discussed previously in this thread?

Do I need to modify a header file or source code file or something?

Have you found any solution? I'm having a similar problem. Using Safenet Soft-PK client on my windows box, travelling through linux 2.4 firewall with iptables. I get disconnected after 12 minutes every time, like clockwork.

I've searched everywhere and the IPsec Masq Table Lifetime paraeter seems to only be in 2.0 kernel. It is not in the config for 2.4. That begs the question of how do I change that parameter?

Please let me know what I can do to stop this. It is pretty frustrating, as you know.

Nope. I suspect you are correct. In this version of the kernal is not there.

I worked around it. I simply used a rule for MASQ of all traffic from the outside VPN server to my Linux box and a similar rule for outgoing. I'm not at my Linux box now so I can't send you the exact details but I specifically specified the address to rewrite the destination address of the incomming packet and the source address for the outoging address. Each rule had the fixed address of the VPN server.

This fixed the problem. I guess there is now a static table entry for the VPN server's ip address. There fore it it does not age the entry out like a dynamic MASQ address (I think?). Using this method I don't think I can setup a second VPN connection throught the firewall - which is ok.

I also had lots of fun getting Free/SWAN to work. That really messed up my kernel. I finally decided to use PPTP and it work fine. Ran well first time. So I now have VPN access into my Linux box and my internal network.

Can you post the commands for that when you get a chance?

Here is the portion that you requested. Substitue X.X.X.X for the VPN server you are trying to reach.



#!/bin/sh
#
# rc.firewal
#
# Define Firewall Rules
#
# Enable Forwarding
#
echo -e "\n\n Loading Firewall Rules \n"
IPTABLES=/sbin/iptables
#
# Define External and Internal interfaces
#
EXTIF="eth0"
INTIF="eth1"
echo " Internal interface: $INTIF"
echo " External interface: $EXTIF"
#
# Deterime External IP Address
#
# I'm being fed an DHCP address on my outside interface, so I
# need to determine what the address is
# dynamically. If you have a static outside interface IP address,
# then everwhere you see $LOCALIP
# substitute you IP address.
#
LOCALIP=`LANG= LC_ALL= ifconfig eth0 | grep 'inet addr' | awk -F: '{ print $2 } ' | awk '{ print $1 }'`
echo " External IP Address: $LOCALIP"

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr

#
# Clear Previous configuration
#
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT DROP
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F

#
# VPN Rules
#

# Inside to Outside VPN
#
# NOTE: X.X.X.X is the IP Address of the VPN server you are wishing to contact
#
# outbound packets
$IPTABLES -A FORWARD -p udp -d X.X.X.X/32 -s 192.168.1.200 -j ACCEPT
$IPTABLES -A FORWARD -p 50 -d X.X.X.X/32 -s 192.168.1.200 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -j SNAT -p udp -d X.X.X.X/32 -s 192.168.1.200/32 --to-source $LOCALIP
$IPTABLES -t nat -A POSTROUTING -j SNAT -p 50 -d X.X.X.X/32 -s 192.168.1.200/32 --to-source $LOCALIP
# inbound packets
$IPTABLES -t nat -A PREROUTING -j DNAT -p udp -s X.X.X.X/32 -d 24.43.0.0/16 --to-destination 192.168.1.200
$IPTABLES -t nat -A PREROUTING -j DNAT -p 50 -s X.X.X.X/32 -d 24.43.0.0/16 --to-destination 192.168.1.200
$IPTABLES -A FORWARD -p udp -s X.X.X.X/32 -d 192.168.1.200 -j ACCEPT
$IPTABLES -A FORWARD -p 50 -s X.X.X.X/32 -d 192.168.1.200 -j ACCEPT

What are the significance of these addresses in your script:

192.168.1.200
24.43.0.0

I'm assuming the 192 addresses is a machine on your LAN, presumably the one with the VPN client trying to get through. No idea on the other one. I'm also fed a DHCP, and use a script similar to yours to determine my external IP, so the $LOCALIP varaible jives.

Thanks for all your help.

Its the provider network.

192.168.x.x is a private, non routable address. Yes its my internal machine (VPN Client) IP address.

By "provider network", do you mean (in my instance) Ameritech's network? Would I just assume that the first 2 parts of my IP would hold true as the provider network?

Sorry if I'm not quite grasping the obvious...

Yes. Its the ISP network your firewall is on.

Just a quick follow up: For those on dynamic addresses (DSL most likely), here is a quick couple of lines to get the outside IP and ISP network addresses:

EXTIP=`ifconfig ppp0 | grep inet | cut -f2 -d:| cut -f1 -d" "`
ISPNET=`expr "$EXTIP" : '\(.*\)\..*\..*'`.0.0

I didn't think that SBC Ameritech would switch networks but sure enough one day my ip was 64.108.x.x and now it is 64.109.x.x, so I put this together.

Cheers.