[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