[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#439520: linux-image-2.6.18-5-686: Unable to connect with VPNC from HOME LAN



>>>>> Bastian Blank <waldi@debian.org>:

> 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;
    }
}



Reply to: