>>>>> Bastian Blank <[EMAIL PROTECTED]>: > No, it is usualy not the same. The Cisco client defaults to NAT > traversal.
The client machine is a laptop with Ubuntu Feisty, which has vpnc 0.4.0. "vpnc -h" gives me the following information on nat-t: ... --natt-mode <natt/none/force-natt/cisco-udp> NAT Traversal Mode <natt/none/force-natt/cisco-udp> Which NAT-Traversal Method to use: * natt -- NAT-T as defined in RFC3947 * none -- disable use of any NAT-T method * force-natt -- always use NAT-T encapsulation even without presence of a NAT device (useful if the OS captures all ESP traffic) * cisco-udp -- Cisco proprietary UDP encapsulation, commonly over Port 10 000 Note: cisco-tcp encapsulation is not yet supported Default: natt Which seems to indicate that nat-t is on by default here as well. I've also been able to use this vpnc client from a different NAT'in site (my father's home LAN, which has a WLAN AP/router with NAT'ing), without any problems. >> When I sniff all NICs on the gateway using Wireshark, I see the >> following traffic when connecting with the Cisco client: > You sniffed on the wrong interface, use the external. If I sniff the external interface I see nothing when attempting to sniff vpnc connect. If I sniff "all" or the internal one, I see the packet below. What's wrong with sniffing all interfaces? It seems to capture the cisco client connect successfully? >> 1. A 914 bytes ISAKMP package on UDP port 500, with source the client >> machine (with a 10.10.10.* address), and destination the VPN gw at >> the workplace > 10.10.10.* is not routable, either you missed to describe parts of your > setup (a NAT box) or you have much more problems. Not sure what you mean here...? I have a home LAN with the 10.10.10.* private IP number range, that gets its IP numbers from the DHCP client of dnsmasq on my gateway machine, and the gateway NATs machines on the inside to the outside. This is a setup I've had for years, and years, and should be pretty straightforward...? Differences from sarge is that I had to start using the DHCP client of dnsmasq, because dnsmasq no longer cooperated with the ISC dhcp daemon, and that I got a 2.6 kernel instead of a 2.4 kernel. vpnc connect to work, through this gateway, worked for me with sarge. The iptables configuration was much simpler for me, when using sarge (see below). With etch the firewall configuration was handled by a tool called ferm (see further below). In sarge I had the following in /etc/networking/interfaces for the outside interface: auto eth1 iface eth1 inet dhcp up /etc/rc.nat The rc.nat file contain the following non-comment lines: modprobe iptable_nat iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward My ferm.conf file in etch looks like this: # -*- shell-script -*- # # Configuration file for ferm(1). # def $DEV_PRIVATE = (eth0); def $DEV_WORLD = eth1; def $NET_PRIVATE = 10.10.10.0/24; table filter { chain INPUT { policy DROP; # connection tracking mod state state INVALID DROP; mod state state (ESTABLISHED RELATED) ACCEPT; # allow local connections interface lo ACCEPT; # respond to ping, but limit that proto icmp { icmp-type echo-request mod limit limit 10/s ACCEPT; DROP; } # for IPsec interface $DEV_WORLD { proto udp dport 500 ACCEPT; proto (esp ah) ACCEPT; # VPNC needs port 4500 UDP open proto udp dport 4500 ACCEPT; } # allow SSH connections from everywhere proto tcp dport ssh ACCEPT; # allow port 119 from everywhere proto tcp dport nntp ACCEPT; # allow secure IMAP from everywhere proto tcp dport imaps ACCEPT; # we provide DNS and SMTP services for the internal net # allow everything from the internal net interface eth0 ACCEPT; # some IRC servers want that interface $DEV_WORLD { proto tcp dport auth ACCEPT; proto tcp dport (8080 3128) REJECT; } # the rest is dropped by the above policy } # outgoing connections are not limited chain OUTPUT policy ACCEPT; chain FORWARD { policy DROP; # connection tracking mod state state INVALID DROP; mod state state (ESTABLISHED RELATED) ACCEPT; # connections from the internal net to the internet or to other # internal nets are allowed interface $DEV_PRIVATE ACCEPT; # the rest is dropped by the above policy } } table nat { chain POSTROUTING { # masquerade private IP addresses saddr $NET_PRIVATE outerface $DEV_WORLD MASQUERADE; } } -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]