i recently upgraded to openvpn 2.3 from 2.2.2. Since then, my openvpn clients can only access some machines on one of the LANs behind the vpn.
openvpn is running on a archlinux router PC. nothing has changed about the configuration. the router is connected to 3 LANs and then has a 4th ethernet to the cable modem. when connected remotely, i can access a wireless access point, printer, and my roomates laptop, but cannot access my machine or any other machine on the 172.16 subnet. it doesn't make sense why some work and some don't... none of the LAN machines have any modifications to their routing tables, and (even more weird) ALL machines on the lan can ping OUT to any VPN client.. but initiating a ping from the client BACK to the LAN machines times out.. ??? for the lif of me, i can't figure out what broke during the upgrade
i am pushing the requisite routes to the clients. here is the server config:
Code:
port 1194
proto udp
dev tun
mssfix 1472
crl-verify crl.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/pLAN9-VPN.crt
key /etc/openvpn/pLAN9-VPN.key
dh /etc/openvpn/dh1024.pem
server 10.11.12.0 255.255.255.0
ifconfig-pool-persist ipp.txt
route 10.11.12.0 255.255.255.0
keepalive 10 50
push "route 172.16.0.0 255.255.0.0"
push "route 10.172.172.0 255.255.255.0"
push "route 192.168.192.0 255.255.255.0"
push "redirect-gateway def1"
client-to-client
tls-auth /etc/openvpn/ta.key 0
cipher AES-128-CBC
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
reneg-sec 10800
mute-replay-warnings
here is client config:
Code:
client
dev tun
port 1194
mssfix 1472
ping-restart 0
dev-node OPENVPN
remote REMOTE_IP
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca "Z:\\keys\\pLAN9\\ca.crt"
cert "Z:\\keys\\pLAN9\\pLAN9-USB.crt"
key "Z:\\keys\\pLAN9\\pLAN9-USB.key"
ns-cert-type server
tls-auth "Z:\\keys\\pLAN9\\ta.key" 1
cipher AES-128-CBC
verb 3
reneg-sec 10800
here is routing table on the gateway. the names of the interfaces are:
external - cable modem
internal - 172.16.x.x subnet, LAN in this example
wifi - a separate public wifi subnet, using iptables tofirewall off access to everything but internet
vpnftp - a direct link to another fileserver box.
Code:
target gateway source proto scope dev tbl
default 70.90.247.34 external
10.11.12.0/ 24 10.11.12.2 tun0
10.11.12.2 10.11.12.1 kernel link tun0
10.172.172.0/ 30 10.172.172.1 kernel link vpnftp
70.90.247.32/ 30 70.90.247.33 kernel linkexternal
172.16.0.0/ 16 172.16.16.1 kernel linkinternal
192.168.192.0/ 24 192.168.192.1 kernel link wifi
10.11.12.1 local 10.11.12.1 kernel host tun0 local
10.172.172.0 broadcast 10.172.172.1 kernel link vpnftp local
10.172.172.1 local 10.172.172.1 kernel host vpnftp local
10.172.172.3 broadcast 10.172.172.1 kernel link vpnftp local
70.90.247.32 broadcast 70.90.247.33 kernel linkexternal local
70.90.247.33 local 70.90.247.33 kernel hostexternal local
70.90.247.35 broadcast 70.90.247.33 kernel linkexternal local
127.0.0.0 broadcast 127.0.0.1 kernel link lo local
127.0.0.0/ 8 local 127.0.0.1 kernel host lo local
127.0.0.1 local 127.0.0.1 kernel host lo local
127.255.255.255 broadcast 127.0.0.1 kernel link lo local
172.16.0.0 broadcast 172.16.16.1 kernel linkinternal local
172.16.16.1 local 172.16.16.1 kernel hostinternal local
172.16.255.255 broadcast 172.16.16.1 kernel linkinternal local
192.168.192.0 broadcast 192.168.192.1 kernel link wifi local
192.168.192.1 local 192.168.192.1 kernel host wifi local
192.168.192.255 broadcast 192.168.192.1 kernel link wifi local
here is output on the gateway of tcpdump logging during a ping test from a vpn client back to one of the LAN machines that i currently cannot access:
Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on internal, link-type EN10MB (Ethernet), capture size 65535 bytes
15:23:42.326559 IP 10.11.12.14 > 172.16.16.11: ICMP echo request, id 1, seq 28, length 40
15:23:46.839805 IP 10.11.12.14 > 172.16.16.11: ICMP echo request, id 1, seq 29, length 40
15:23:51.842466 IP 10.11.12.14 > 172.16.16.11: ICMP echo request, id 1, seq 30, length 40
15:23:56.840276 IP 10.11.12.14 > 172.16.16.11: ICMP echo request, id 1, seq 31, length 40
as you can see, packets are getting sent to 172.16.16.11 but not being replied to. This particular machine has no firewall and responds to pings from inside the LAN no problem. Running tcpdump on 172.16.16.11 shows essentially the same thing; ICMP echo requests are received, but no reply is sent. As i said, i can, weirdly, ping remote vpn clients (in this case FROM 172.16.16.11 out to 10.11.12.14) no problem, so i don't get why there's only a one-way traffic flow.
any thoughts?
EDIT heres iptables.rules:
Code:
# Generated by iptables-save v1.4.12.1 on Fri Dec 16 23:02:51 2011
*nat
:PREROUTING ACCEPT [281:34682]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [36:2520]
:POSTROUTING ACCEPT [54:3432]
-A PREROUTING -i external -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.16.3
-A PREROUTING -i external -p tcp -m tcp --dport 12345 -j DNAT --to-destination 172.16.16.10
-A PREROUTING -i external -p tcp -m tcp --dport 12346 -j DNAT --to-destination 172.16.16.11
-A PREROUTING -i external -p tcp -m tcp --dport 12347 -j DNAT --to-destination 172.16.16.12
-A PREROUTING -i external -p tcp -m tcp --dport 12348 -j DNAT --to-destination 172.16.16.13
-A PREROUTING -i external -p tcp -m tcp --dport 12349 -j DNAT --to-destination 172.16.16.15
-A POSTROUTING -s 172.16.0.0/16 -o external -j MASQUERADE
-A POSTROUTING -s 192.168.192.0/24 -o external -j MASQUERADE
-A POSTROUTING -s 10.11.12.0/24 -o external -j MASQUERADE
COMMIT
# Completed on Fri Dec 16 23:02:51 2011
# Generated by iptables-save v1.4.12.1 on Fri Dec 16 23:02:51 2011
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2486:1827440]
:LOGDROP - [0:0]
:TCP - [0:0]
:UDP - [0:0]
:fw-interfaces - [0:0]
:fw-open - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i internal -j ACCEPT
-A INPUT -i wifi -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i vpnftp -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j LOGDROP
-A INPUT -i external -d 255.255.255.255 -j DROP
-A INPUT -p udp --dport 1194 -j ACCEPT
-A INPUT -j LOGDROP
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.11.12.0/24 -i tun+ -j ACCEPT
-A FORWARD -s 10.11.12.0/24 -i vpnftp -j ACCEPT
-A FORWARD -s 10.11.12.0/24 -j ACCEPT
-A FORWARD -s 192.168.192.0/24 -d 172.16.0.0/16 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -s 192.168.192.0/24 -d 10.172.172.0/24 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -s 192.168.192.0/24 -d 10.100.100.0/24 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -s 192.168.192.0/24 -d 10.11.12.0/24 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m iprange --src-range 192.168.192.3-192.168.192.251 -d 172.16.16.1 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j fw-interfaces
-A FORWARD -j fw-open
# -A LOGDROP -j LOG
-A LOGDROP -j DROP
-A fw-interfaces -i internal -j ACCEPT
-A fw-interfaces -i wifi -j ACCEPT
-A fw-interfaces -i tun+ -j ACCEPT
-A fw-interfaces -i vpnftp -j ACCEPT
-A fw-open -d 172.16.16.3/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A fw-open -d 172.16.16.10/32 -p tcp -m tcp --dport 12345 -j ACCEPT
-A fw-open -d 172.16.16.11/32 -p tcp -m tcp --dport 12346 -j ACCEPT
-A fw-open -d 172.16.16.12/32 -p tcp -m tcp --dport 12347 -j ACCEPT
-A fw-open -d 172.16.16.13/32 -p tcp -m tcp --dport 12348 -j ACCEPT
-A fw-open -d 172.16.16.15/32 -p tcp -m tcp --dport 12349 -j ACCEPT
COMMIT
# Completed on Fri Dec 16 23:02:51 2011
SOLVED: so apparently even when Windows 7 firewall is set to "private", it still will not allow access to clients from a different subnet than the one it's connected to. as such, Win7 machine with LAN ip 172.16.16.11 could INITIATE traffic out to a VPN client 10.11.12.18, but would not allow traffic IN. allowing all traffic from 10.11.12.0 in the Win7 firewall fixed this issue.
*facepalm*
