I'm attempting to use a Nortel Contivity VPN Client on a box behind OpenWRT, still a mostly default setup on WhiteRussian RC4.  (And unfortunately, there doesn't seem to be any "NAT Traversal" option available on my client configuration.)

The problem starts when I try to setup "DMZ" forwarding.  (See http://forum.openwrt.org/viewtopic.php?id=4030 for more details.)  The moment I do this, I start seeing the following errors, as reported by tcpdump:

tcpdump -i vlan1 host (vpn) -N
...
01:13:47.298478 IP (vpn) > (my_wan_ip): ESP(spi=0x...,seq=0x1)
01:13:47.299151 IP (my_wan_ip) > (vpn): icmp 128: (my_wan_ip) protocol 50 port 58887 unreachable

(Sometimes it just says "protocol 50 unreachable" without the port #, sometimes it shows it with as above - not sure why...)

Here's the relevant information from my firewall.user:

### IPSEC-DMZ Fix
iptables -t nat -A postrouting_rule -p esp -j ACCEPT

### Allow ping from WAN for testing.
iptables -A input_rule -d $WAN_IP -p icmp --icmp-type echo-request -j ACCEPT

### DMZ (should be placed after port forwarding / accept rules)
iptables -t nat -A prerouting_rule -d $WAN_IP -j DNAT --to $DMZ_IP
iptables        -A forwarding_rule -d $DMZ_IP -j ACCEPT
iptables -t nat -A postrouting_rule -s (my subnet) -d $DMZ_IP -j MASQUERADE

Here's the interesting part:  Having this in /etc/firewall.user during reboot seems to cause the VPN to fail regardless of whatever I do later.  If I use the default firewall.user, reboot, copy it to /tmp, make changes, then run the script, things seem to work fine.  I've repeated this with duplicate results several times.  Even having the above changes in /etc/firewall.user, and calling it again doesn't work - having the changes there during boot seems to be the issue.

Is there something happening differently between having this run during reboot or configuring it later?  Supposedly everything in iptables is being flushed due to the -F's at the top of the file.

(Note that this did NOT work any better under the native Linksys firmware - which is reason that compelled me to try OpenWrt in the first place.  At least here, I have the ability to debug...)

Edit:
Another thing I just found.  Looking at the tcpdump logs again, sometimes the logs show everything coming from me as having my external WAN IP address - other times they are appearing as having the computer's LAN IP address.  I've not been able to find a reason for this one way or another.  I'm really down to only trying to configurations - my modified version (above) and the default from /rom/etc/firewall.user.  However, I may see either the WAN or LAN IP address under either firewall.user version.  I have NO IDEA why this changes.  (2 configuration possibilities seem to be resulting in 6+ types of packet dumps.)

Any suggestions would be greatly appreciated - thanks!!

(Last edited by ziesemer on 16 Jan 2006, 09:55)

I GOT IT!!

The following line added underneath the "### Port forwarding" section in the default /etc/firewall.user did the trick:

iptables -t nat -A prerouting_rule -p esp -j ACCEPT

Why?
(Here's my attempt - please feel free to correct me, as I'm still trying to understand all the details.)

Enabling "DMZ" in the default /etc/firewall.user would try to DNAT and forward ALL incoming packets, including esp, which won't work for a few reasons.  First, the DMZ host may not be the same client attempting to make a VPN connection.  Second, trying to use NAT changes the destination address of the packets, and with esp packets, this invalidates the checksum.  Including the above prerouting_rule before the related DMZ rule will exclude esp packets from being DNAT'd and forwarded, and instead go back to the default target of ACCEPT.

My postrouting_rule attempt didn't hurt anything, but wasn't necessary, as all packets going out to vlan1 (the WAN) are already masqueraded.

I AM CURIOUS as to how the esp packets ever make it back to the client from the VPN server.  As seen through tcpdump, the incoming packets are only marked with a destination of the WAN IP address.  There are no visible port numbers to NAT by, as they are encrypted within esp.  Is there something that keeps track of the outgoing spi and maybe seq #'s to forward them back to the originating client?

Hi zeismer,

It just so happens I'm trying to do the exact same thing as you.  I'm using the Nortel [Contivity VPN client on a laptop and I'm running a wl500g with RC4 on it as my internet router.

Is the

iptables -t nat -A prerouting_rule -p esp -j ACCEPT

rule the only custom rule in either your firewall.user or S45firewall scripts?
I ask because I have added that rule to my firewall.user and I can't get it to work.  Are you using DMZ or port-forwarding do deal with NAT?  IPSEC apparently uses UDP port 500, I've tried port-forwarding this port to my VPN client laptop and it doesn't work then either.

First of all, try this with a default /etc/firewall.user.  Copy the one from /rom/etc/firewall.user to be sure.  It should work fine.  If not, there's another problem here...

The only reason I needed my above fix was because I enabled DMZ for other reasons (my only applicable change being the uncommenting of the default DMZ rules at the bottom of the file).  By doing this, I effectively broke the default rules that handled things properly for IPSEC VPN.  By placing the above rule somewhere above the DMZ rules, anything matching "-p esp" will no longer be handled and broke by the DMZ rules.  Read through my attempt at "Why" above.

As for UDP 500, I'd definitely try to stop forwarding that - I'm guessing it's causing more problems than it's solving.  When using tcpdump to watch the traffic on my router while troubleshooting this, nothing seen as UDP 500 was a problem.  As I recall, the only thing seen as UDP 500 is the initial key exchange (IKE) which completed without any issues.  The problems started happening after that, but while the packets may have still been UDP 500, they are encapsulated using ESP, so UDP 500 no longer even applies.