1

Short résumé

No errors, no dropped packets, pings reach clients, tcpdump shows packages travelling, everything else never reaches the LAN hosts (or OpenVPN clients).

Edit

After trying to eliminate all possible disruptive factors, I reconfigured my VM setup to use bridges instead of MacVTap. Now access to LAN clients works as expected. I hope this is not the ultimate answer (I'd like to keep MacVTap).

I've done a little bit of VM stuff and networking before, still such a behaviour as described below is completely new to me.

Edit: What strikes me most is that the responses (e.g. DNS query) are routed back to the client (I added a tcpdump of that), yet dig still runs into a timeout.

I've been scratching my head over this for some days now and I can't find anything on the interwebz (maybe weak search-fu), so I thought it was time for you ServerFaulters out there.

Task (essentially easy): Setup an OpenVPN server, route traffic to LAN behind it.

Problem: Pings succeed, "everything else" doesn't. On the host there's a DNS server running as well as an OpenSSH-Server, both of which can't be reached.

I thought that there might be masquerading / NATing involved, but that was not the culprit at all.

Actually, I think I'm just too stupid right now. So, please, help a desparate guy (and don't hesitate to ask for even more details).

Setup

VPN-Server and Host are VMs running on a Machine VPN-Client is directly connected to. Boths VMs can see each other, iptables policies are set to ACCEPT on all hosts.

OpenVPN-Server

eth0    10.0.0.3
tun0:1  172.16.0.3
tun0    10.8.0.1

# cat /proc/sys/net/ipv4/ip_forward
1

# lsmod
xt_conntrack           12681  3 
iptable_filter         12536  1 
ipt_MASQUERADE         12594  3 
iptable_nat            12646  1 
nf_conntrack_ipv4      18499  4 
nf_defrag_ipv4         12483  1 nf_conntrack_ipv4
nf_nat_ipv4            12912  1 iptable_nat
nf_nat                 22379  3 ipt_MASQUERADE,nf_nat_ipv4,iptable_nat
nf_conntrack           70753  6 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,xt_conntrack,iptable_nat,nf_conntrack_ipv4
ip_tables              21914  2 iptable_filter,iptable_nat
x_tables               23015  4 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter
[…]

/etc/openvpn/server.conf

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
topology subnet # is this actually needed?

VPN-Client

eth0 172.16.0.100
tun0 10.8.0.4

$ ip route
10.0.0.0/24 via 10.8.0.1 dev tun0 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.4 
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.100

OpenVPN connection (excerpts)

$ sudo openvpn --config vpn.ovpn
…
UDPv4 link remote: [AF_INET]172.16.0.3:1194
TLS: Initial packet from [AF_INET]172.16.0.3:1194, sid=b636ac88 2ef4c575
[…] Peer Connection Initiated with [AF_INET]172.16.0.3:1194
SENT CONTROL […]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0'
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 10.8.0.4/24 broadcast 10.8.0.255
/sbin/ip route add 10.0.0.0/24 via 10.8.0.1

Host

eth0 10.0.0.2

$ ip route
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.2 
10.8.0.0/24 via 10.0.0.3 dev eth0

ICMP Echo

As you can see below, pings success from VPN-Client to Host. (Pings from Host to VPN-Client work equally well, but I omitted them here)

This was done without any iptables rules.

VPN-Client

$ ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.30 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.303/1.303/1.303/0.000 ms

OpenVPN-Server

tcpdump -i tun0
11:01:25.787428 IP 10.8.0.4 > 10.0.0.2: ICMP echo request, id 4209, seq 1, length 64
11:01:25.787899 IP 10.0.0.2 > 10.8.0.4: ICMP echo reply, id 4209, seq 1, length 64

Host

# tcpdump net 10.8.0.0/24
11:01:25.797640 IP 10.8.0.4 > 10.0.0.2: ICMP echo request, id 4209, seq 1, length 64
11:01:25.797682 IP 10.0.0.2 > 10.8.0.4: ICMP echo reply, id 4209, seq 1, length 64

DNS Query

Again, no iptables rules.

VPN-Client

$ dig @10.0.0.2 serverfault.com

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Debian-1:9.9.3.dfsg.P2-4 <<>> @10.0.0.2 serverfault.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Edit: Connection times out, yet there's a response that can be seen in tcpdump:

# tcpdump -i tun0
14:26:26.609399 IP vpnclient.56553 > 10.0.0.2.domain: 44738+ [1au] A? serverfault.com. (44)
14:26:26.738504 IP 10.0.0.2.domain > vpnclient.56553: 44738$ 1/0/0 A 198.252.206.16 (49)

OpenVPN-Server

# tcpdump -i tun0
10:03:52.077784 IP 10.8.0.4.58792 > 10.0.0.2.domain: 61705+ [1au] A? serverfault.com. (44)
10:03:52.092420 IP 10.0.0.2.domain > 10.8.0.4.58792: 61705$ 1/0/0 A 198.252.206.16 (49)

Host

# tcpdump net 10.8.0.0/24
10:03:57.061048 IP 10.8.0.4.58792 > 10.0.0.2.domain: 61705+ [1au] A? serverfault.com. (44)
10:03:57.075223 IP 10.0.0.2.domain > 10.8.0.4.58792: 61705$ 1/0/0 A 198.252.206.16 (49)
Alex
  • 538
  • 1
  • 4
  • 15
  • Why do you need NAT? – Laurentiu Roescu Dec 11 '13 at 11:43
  • @LaurentiuRoescu Honestly I don't know. Do I need NAT if I (later) want to allow VPN clients to access the internet via the VPN-Server's default gateway? According to https://community.openvpn.net/openvpn/wiki/BridgingAndRouting I only need connection tracking, but following that guide didn't work either. – Alex Dec 11 '13 at 12:05
  • You will need NAT to allow VPN clients to access internet via VPN server. As you will also need NAT to allow LAN to acces internet. – Laurentiu Roescu Dec 11 '13 at 13:15
  • Oh, I think I got you wrong. Yeah, sure, I'll need NAT on the gateway, but that's already configured properly at 10.0.0.1 (and 10.0.0.0/24 does have full internet access). I'm not pushing the default route through OpenVPN yet because simple LAN access doesn't work. – Alex Dec 11 '13 at 13:37

1 Answers1

0

Try starting with these rules in firewall:

iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 10.0.0.0/24 -j ACCEPT

It should allow full communication between LAN and VPN clients.

Laurentiu Roescu
  • 2,266
  • 17
  • 17
  • Thanks for your suggestions. I'm a bit confused here: How could an ACCEPT rule allow full communication between LAN and VPN if the FORWARD chain's policy is already set to ACCEPT? I tried those rules but unfortunately they don't help. The rules do apply to e.g each DNS request by the way, so there's one packet for each rule in iptables' output. – Alex Dec 11 '13 at 13:49
  • Ok, so if policy is accept and no other DENY rule exists then those lines above are useless. What I want to suggest is to remove NAT, I don't think you need it. Routing should be enough. – Laurentiu Roescu Dec 11 '13 at 14:06
  • Yes, I did all my tests without NAT (and also trying to follow the guide at linked above). Still, ICMP works, TCP/UDP don't. – Alex Dec 11 '13 at 15:14
  • Can you post a tcpdump of a DNS query without any firewall rules? I think that 2 way masquerading cause problems. Without it should work. – Laurentiu Roescu Dec 11 '13 at 16:03
  • Beside this, the only o thing that come to my mind is MTU. Try to set a lower MTU for tun0 (for example 1460). – Laurentiu Roescu Dec 11 '13 at 16:26
  • Requested dump edited into post. I tried with MTU 1460 on both client tun0 and server, no changes at all (actually, the dump I added was done with changed MTU size). – Alex Dec 12 '13 at 09:06