[CLUE-Tech] Marginally OT: VPN client

David Anselmi anselmi at americanisp.net
Mon Aug 11 20:18:43 MDT 2003


Sean LeBlanc wrote:
[...]
> That option about IPSec over UDP is the default, and I was told to use that.
> A co-worker has cable, and he had the following in iptables:
> 
>    -A INPUT -i eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>    -A OUTPUT -o eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>    -A INPUT -i eth0 -p 50 -j ACCEPT
>    -A OUTPUT -o eth0 -p 50 -j ACCEPT

This is appropriate for firewall rules on the client.  If the firewall 
was between the client and server you would use the FORWARD chain rather 
than INPUT and OUTPUT.

> For grins, I did what I thought would be the Cisco 678 translation:
> 
> set nat entry add 10.0.0.2 500 
> set nat entry add 10.0.0.2 0 50

No, the 678 equivalent to INPUT and OUTPUT is "set fi" -- the packet 
filters.  "set nat" is the equivalent of "iptables -t nat -A 
PREROUTING".  Your entries allow the Internet to connect to your 
10.0.0.2 box (assuming no filtering).

For your client you don't need this -- the SNAT the 678 does for you is 
automatic (if you have nat enabled).

Try running ethereal on your client.  I bet that what you'll see is 3 or 
4 ISAKMP packets go out (UDP port 500 on both ends).  But nothing will 
come back.  So either something is blocking the packets before they get 
to the server or it's blocking the packets coming back to you.

I'm guessing you don't have access to both ends of this connection (you 
could use netcat or something to test with then).  Have you talked to 
the VPN admin?  The two times I've done this (different admins) it was 
their end in both cases.

Good luck!
Dave




More information about the clue-tech mailing list