Iptables – How to access remote lan machines through a ipsec / xl2ptd vpn (maybe iptables related)

ipseciptablesl2tpvpn

I’m trying to do the setup of a IPSEC / XL2TPD VPN for our office, and I’m having some problems accessing the remote local machines after connecting to the VPN.

I can connect, and I can browse Internet sites trough the VPN, but as said, I’m unable to connect or even ping the local ones.

My Network setup is something like this:

INTERNET > eth0 > ROUTER / VPN > eth2 > LAN

These are some traceroutes behind the VPN:

traceroute to google.com (173.194.78.94), 64 hops max, 52 byte packets
 1  192.168.1.80 (192.168.1.80)  74.738 ms  71.476 ms  70.123 ms
 2  10.35.192.1 (10.35.192.1)  77.832 ms  77.578 ms  77.865 ms
 3  10.47.243.137 (10.47.243.137)  78.837 ms  85.409 ms  76.032 ms
 4  10.47.242.129 (10.47.242.129)  78.069 ms  80.054 ms  77.778 ms
 5  10.254.4.2 (10.254.4.2)  86.174 ms
    10.254.4.6 (10.254.4.6)  85.687 ms
    10.254.4.2 (10.254.4.2)  85.664 ms

traceroute to 192.168.1.3 (192.168.1.3), 64 hops max, 52 byte packets
 1  * * *
 2  *traceroute: sendto: No route to host
traceroute: wrote 192.168.1.3 52 chars, ret=-1
 *traceroute: sendto: Host is down
traceroute: wrote 192.168.1.3 52 chars, ret=-1
 *
traceroute: sendto: Host is down
 3 traceroute: wrote 192.168.1.3 52 chars, ret=-1
 *traceroute: sendto: Host is down
traceroute: wrote 192.168.1.3 52 chars, ret=-1

These are my iptables rules:

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# allow lan to router traffic
iptables -A INPUT -s 192.168.1.0/24 -i eth2 -j ACCEPT

# ssh
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

# vpn
iptables -A INPUT -p 50 -j ACCEPT
iptables -A INPUT -p ah -j ACCEPT
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p udp --dport 1701 -j ACCEPT

# dns
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 53 -j ACCEPT

iptables -t nat -A POSTROUTING -j MASQUERADE

# logging
iptables -I INPUT 5 -m limit --limit 1/min -j LOG --log-prefix "iptables denied: " --log-level 7

# block all other traffic
iptables -A INPUT -j DROP

And here are some firewall log lines:

Dec  6 11:11:57 router kernel: [8725820.003323] iptables denied: IN=ppp0 OUT= MAC= SRC=192.168.1.81 DST=192.168.1.3 LEN=60 TOS=0x00 PREC=0x00 TTL=255 ID=62174 PROTO=UDP SPT=61910 DPT=53 LEN=40 
Dec  6 11:12:29 router kernel: [8725852.035826] iptables denied: IN=ppp0 OUT= MAC= SRC=192.168.1.81 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=15344 PROTO=UDP SPT=56329 DPT=8612 LEN=24 
Dec  6 11:12:36 router kernel: [8725859.121606] iptables denied: IN=ppp0 OUT= MAC= SRC=192.168.1.81 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=11767 PROTO=UDP SPT=63962 DPT=8612 LEN=24 
Dec  6 11:12:44 router kernel: [8725866.203656] iptables denied: IN=ppp0 OUT= MAC= SRC=192.168.1.81 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=11679 PROTO=UDP SPT=57101 DPT=8612 LEN=24 
Dec  6 11:12:51 router kernel: [8725873.285979] iptables denied: IN=ppp0 OUT= MAC= SRC=192.168.1.81 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=39165 PROTO=UDP SPT=62625 DPT=8612 LEN=24

I’m pretty sure that the problem should be related with iptables, but after trying a lot of different confs, I was unable to find the right one.

Any help will be greetly appreciated ;). Kind regards, Simon.

EDIT:

This is my route table:

default         62.43.193.33.st 0.0.0.0         UG    100    0        0 eth0
62.43.193.32    *               255.255.255.224 U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth2
192.168.1.81    *               255.255.255.255 UH    0      0        0 ppp0

Best Answer

You are very likely having the exact same issue as this post

Your situation is as follow:

VPN client can reach VPN server and tunnel through VPN to the internet, but cannot reach server LAN nor any other VPN clients ip.

Tunneling to the internet work because you have iptables NAT rule. The rest you need to apply the following ON THE VPN SERVER:

Enable tcp/ip forwarding

Linux TCP/IP stack by default does not forward packets (either between interfaces or re-routing them between IP network). It has to be enabled

echo 1 > /proc/sys/net/ipv4/ip_forward

Without that, VPN server will accept VPN client packet locally, and route client packet according to NAT rule, but will not route traffic to local network.

Iptables

Iptables block all traffic by default. You need rules to allow traffic to get through(forward).

$IPTABLES -A FORWARD -s 192.168.1.0/24 -d 192.168.1.0/24 -j ACCEPT

PS: Each vpn connection is an individual(virtual) interface(nic), to allow packet to flow/route between them, you need FORWARD in iptables.

/etc/l2tpd.conf

When vpn client need to talk to each together, the vpn server is acting as a routing point and need to be on the same netowrk.

local ip 192.168.1.1
ip range 192.168.1.2 - 192.168.1.254

Modify the above according to your network setup. If your vpn server has a 192.168.1.x ip, use it for the "local ip".

Modified Iptables script

Be very careful if you don't have physical access to the vpn server.

(This script will need anti-spoofing on the wan interface, but lets focus on getting traffic from vpn to lan 1st.)

# Reset/Flush iptables
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT
# -- iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
#
# Updated NAT rule
#   External interface  = eth0
#   External IP     = 123.123.123.123
#   Internal LAN        = 192.168.1.0/24
#   To support dynamic interface : "-j SNAT" replace "-j MASQUERADE" 
#   NO NAT if destination is LAN 
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 ! -d 192.168.1.0/24 -j SNAT --to-source 123.123.123.123

# New(1) - lo
# -- iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i lo   -m state --state NEW  -j ACCEPT
iptables -A OUTPUT -o lo   -m state --state NEW  -j ACCEPT

# -- iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# New(2) Allow inter-192.168.1.x routing
iptables -A INPUT  -s 192.168.1.0/24   -m state --state NEW  -j ACCEPT
iptables -A OUTPUT  -s 192.168.1.0/24   -m state --state NEW  -j ACCEPT
iptables -A FORWARD  -s 192.168.1.0/24   -m state --state NEW  -j ACCEPT

# -- allow lan to router traffic - Shadowed by New(2)
# -- This rule maybe your source of trouble too, it only accept 192.168.1.x from eth2
# -- iptables -A INPUT -s 192.168.1.0/24 -i eth2 -j ACCEPT

# ssh
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

# vpn
iptables -A INPUT -p 50 -j ACCEPT
iptables -A INPUT -p ah -j ACCEPT
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p udp --dport 1701 -j ACCEPT

# dns - Shadowed by New(2)
# -- iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 53 -j ACCEPT
# -- iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 53 -j ACCEPT

# logging
iptables -I INPUT 5 -m limit --limit 1/min -j LOG --log-prefix "iptables denied: " --log-level 7

# block all other traffic
iptables -A INPUT -j DROP

Related Solutions

Iptables ESTABLISHED,RELATED chain problems

Netfilter has dropped the connection from the state table. One of the timeouts in /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_* has expired. I'm guessing it is nf_conntrack_tcp_timeout_last_ack.

Here is a scenario: Your web server sends a final packet with some data and fin set. The client goes comatose for 30 seconds. Netfilter removes the entry from the state table. The client wakes up and sends a fin ack that is not part of a tracked connection anymore.

I see this all the time on web servers. It is client problem.

If you want to verify that you could record the state table (/proc/net/nf_conntrack) and correlate that with the firewall log.

Edit: I had the direction reversed but the concept applies. In this case his server is making outgoing https connections so it is actually the client and the remote web server may be slow to respond.

The rule

/sbin/iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT

has nothing to do with it. It is about DST port 443 and this is SPT 443.

Iptables: How to read this OPT string

0204057D010303010101080A3E521D4D0000000004020000
From a sans.org study guide,
the first 2 bytes (0x0204) 04--is-length 02 means MSS flag
the next 2 bytes (0x057D) are the value for maximum size segment (MSS)
the next byte (0x01) is a no-op
the next 2 bytes (0x0303) indicate a windows scaling is enabled

the 3 bytes ("010101") are no-ops (AKA padding)
the 2 next bytes ("080a") flag a time stamp value
the 4 next bytes (("0x3E521D4D00000000") are date time 5 * 2 bytes
the 4 next bytes ("0402") sAck Ok

The master document: ftp://ftp.ietf.org/iana/tcp-parameters/tcp-parameters.xml
Others: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-security-03
http://www.ietf.org/mail-archive/web/tcpm/current/msg03199.html

for humor! : https://www.rfc-editor.org/rfc/rfc5841

Best Answer

Related Solutions

Iptables ESTABLISHED,RELATED chain problems

Iptables: How to read this OPT string

Related Topic