VPN and WOL

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
slipry79
DD-WRT Novice


Joined: 20 Dec 2016
Posts: 7

PostPosted: Sun Mar 11, 2018 16:24    Post subject: VPN and WOL Reply with quote
I am hoping someone can help explain the behavior I am getting with a VPN and my WOL setup.

After quite a bit of trial and error, I think I have Cyberghost VPN working on my router. I have a Linksys WRT1900ACS V2 running DD-WRT v3.0-r33555 std (10/20/17). I followed the Cyberghost router guide with the following exceptions/additions:
- Used the Cyberghost DNS addresses (38.132.106.139 and 194.187.251.670) in the Network Address Server Settings (DHCP) section of Setup in the DD-WRT GUI.
- Used the username and password fields in the DD-WRT OpenVPN Client setup GUI and did not use the startup commands to create the temporary username/password file.
- Enabled NAT and Firewall Protection in the OpenVPN Client setup.
- Omitted the "explicit-exit-notify 2" line from the Additional Config commands in the OpenVPN Client setup.
- Did not use any Firewall startup commands.

Now to explain my WOL setup:
I have a DDNS through afraid.org. I also have port 9 forwarded to 192.168.1.254 in the router, and I have an arp startup command to broadcast the traffic that comes to 192.168.1.254. The DDNS has not updated yet, and the DDNS host name still resolves to my "true" IP address.

Here is the mystery... WOL works with all of the following addresses: the DDNS host name, my true IP address, and my new VPN IP address. I would not have expected it to work with either the host name prior to DDNS update or my true IP address. Does Port Forwarding and/or the arp command allow the incoming WOL packet to bypass the VPN? Have I defeated (or at least partially defeated) the security of the VPN this way?

Here is one other piece of info:
I enabled Anonymous WAN Requests (ping). From an external computer, pings to the DDNS host name and my true IP address fail. Pings to the new VPN IP address succeed. Is this because pings are handled differently than forwarded ports and are therefore successfully blocked by the VPN?

Any comments would be appreciated.
Sponsor
slipry79
DD-WRT Novice


Joined: 20 Dec 2016
Posts: 7

PostPosted: Sun Mar 11, 2018 23:08    Post subject: Reply with quote
Thanks very much for your response.

First, let me clarify which IP addresses I am referring to in case I caused any confusion. I will call the IP address my ISP assigns the "ISP address", and I will call the public IP address that the VPN assigns the "VPN address".

I read your prior post, and I confirmed that I cannot access my router GUI from a computer outside my LAN with either the VPN address or the ISP address.

I also confirmed with an outside computer that sending the WOL command to my numeric (dotted quad) ISP address still causes my computer to wake up with the VPN running. So even with the DDNS hostname out of the picture, the WOL packet still makes it to my computer when I use the numeric ISP address.

I do want to be able to continue to wake the computer from outside the LAN, but it still puzzles me that the ISP address would continue to work in addtion to the VPN address. I expected that I would have to start using the VPN address exclusively and get the DDNS to update to the VPN address to be able to use the hostname.

I will also note that the Cyberghost guide recommended the following firewall rules that I did not implement:

iptables -I FORWARD -i br0 -o tun1 -j ACCEPT
iptables -I FORWARD -i tun1 -o br0 -j ACCEPT
iptables -I INPUT -i tun1 -j REJECT
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

I did not use these rules because it seemed like other posts said that they were not needed if NAT and Firewall Protection are enabled in the GUI. I see that you are skeptical of the rules that DD-WRT implements, so I looked at the rules you suggested in your other post, but it seems my needs are different. I will admit that the iptables rules are beyond my grasp without some more study.

I will try the Cyberghost rules next and see if that changes the behavior.

Any other comments or light you can shine on this would be appreciated.
slipry79
DD-WRT Novice


Joined: 20 Dec 2016
Posts: 7

PostPosted: Mon Mar 12, 2018 14:34    Post subject: Reply with quote
Thanks again. This info was very helpful for my understanding the functions and the sequence of what is going on with the VPN. I will do some more testing and report back.

I have also found that I am still not reliably connecting to the Cyberghost VPN server after reboot of the router, so I will keep working on that as well.
slipry79
DD-WRT Novice


Joined: 20 Dec 2016
Posts: 7

PostPosted: Tue Mar 13, 2018 22:47    Post subject: Reply with quote
After further testing, here is what I have found:

1) Connection issues
The Cyberghost setup guides and related info lead you to use vpn server names of the following form: "1-us.cg-dialup.net".

If you do a nslookup on that hostname it resolves to multiple ip addresses. This is supposedly a good feature so you always get a server that is available and has capacity. The individual servers have names like atlanta-s01-i01.cg-dialup.net, and those hostnames resolve to one unique ip address each.

What I believe is going on is that the individual servers behave differently. Here is a fragment of the syslog when the router successfully connects to a server:
Code:
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: SENT CONTROL [CyberGhost VPN Server Node atlanta-s02]: 'PUSH_REQUEST' (status=1)
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 38.132.106.139,dhcp-option DNS 194.187.251.67,dhcp-option DNS 185.93.180.131,comp-lzo yes,route 10.253.200.1,topology net30,ifconfig 10.25
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: OPTIONS IMPORT: compression parms modified
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: NOTE: --mute triggered...
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: 6 variation(s) on previous 3 message(s) suppressed by --mute
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: Data Channel: using negotiated cipher 'AES-256-GCM'
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: TUN/TAP device tun1 opened
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: TUN/TAP TX queue length set to 100
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: /sbin/ifconfig tun1 10.253.201.22 pointopoint 10.253.201.21 mtu 1500
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: /sbin/route add -net 213.159.14.11 netmask 255.255.255.255 gw 24.3.136.1
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.253.201.21
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.253.201.21
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: /sbin/route add -net 10.253.200.1 netmask 255.255.255.255 gw 10.253.201.21
Mar 13 02:15:33 Linksys-WRT1900 daemon.notice openvpn[2047]: Initialization Sequence Completed


Here is a fragment of the syslog when the router fails to connect:
Code:
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: SENT CONTROL [CyberGhost VPN Server Node washington-s05]: 'PUSH_REQUEST' (status=1)
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 38.132.106.139,dhcp-option DNS 194.187.251.67,dhcp-option DNS 185.93.180.131,comp-lzo yes,tun-ipv6,route 10.252.200.1,
Mar 12 23:07:25 Linksys-WRT1900 daemon.warn openvpn[2049]: Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: OPTIONS IMPORT: compression parms modified
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: OPTIONS IMPORT: --ifconfig/up options modified
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: OPTIONS IMPORT: route options modified
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: NOTE: --mute triggered...
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: 4 variation(s) on previous 3 message(s) suppressed by --mute
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: Data Channel: using negotiated cipher 'AES-256-GCM'
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: GDG6: remote_host_ipv6=n/a
Mar 12 23:07:25 Linksys-WRT1900 daemon.warn openvpn[2049]: GDG6: NLMSG_ERROR: error Not supported
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: TUN/TAP device tun1 opened
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: TUN/TAP TX queue length set to 100
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: /sbin/ifconfig tun1 10.252.202.118 pointopoint 10.252.202.117 mtu 1500
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: /sbin/ifconfig tun1 add 2605:3e80:1f01::502:200:0:109c/112
Mar 12 23:07:25 Linksys-WRT1900 daemon.err openvpn[2049]: Linux ifconfig inet6 failed: external program exited with error status: 1
Mar 12 23:07:25 Linksys-WRT1900 daemon.notice openvpn[2049]: Exiting due to fatal error

The difference seems to be that the "bad" server pushes the route_ipv6 option. I have ipv6 disabled, and this appears to cause the openvpn process to fail when it attempts to process the option.

I tried to override the route_ipv6 option with Additional Config commands in the GUI, but nothing I tried worked. I don't think it is possible, but if anyone has any ideas, please let me know.

I could of course enable ipv6 in the GUI and I assume it would work, but I really don't want the additional complexity of ipv6 right now, and it seems like the firmware should be capable of rejecting the route_ipv6 option with ipv6 disabled.

The workaround that I used successfully is to specify a unique known "good" server address. I could also use multiple known good server addresses with the commands that eibgrad suggested in the previous post, but it is unfortunate you can't use the 1-us.cg-dialup.net style server name as Cyberghost intended. I would also assume that the configuration of the servers could change in the future and turn good servers into bad.

Note that I upgraded to r35244 just to see if this behavior might have changed, but it did not.

2) Routing and WOL
I still don't completely understand the networking principles of VPNs, but I don't believe that Cyberghost assigns a unique public IP address to my VPN connection. When I use whatismyipaddress.com while connected to the VPN, it shows the same VPN server address I used in the setup. I therefore believe that the same public IP address is assigned to every VPN user on that server and that computers outside the VPN would have no way of initiating connections to my computer. If this is wrong, maybe someone can explain the networking principles behind what is going on. What I believe I would need to make externally initiated connections possible would be for Cyberghost to assign a unique static public IP address when I connect. It would appear that some VPN providers have this service for an extra fee, but I don't think Cyberghost provides that service anymore.

I think WOL continues to work with my ISP address because of the port forwarding rule I have in place and because I have not explicitly tried to implement firewall rules that reject incoming packets to the ISP address. I assume that as eibgrad states, since no response to the WOL is required, it does not matter whether an outgoing acknowledgement is rejected in the router.

Note that I now think my earlier report that WOL was working with the public IP address from the VPN was wrong. I think my computer woke up coincidentally a few seconds after I ran the previous test. I tested it several times since then with the VPN connected and it never worked again.

3) DDNS
Again, I am not sure I am looking at this correctly, but I think that when forcing my DDNS to update after being connected to the VPN, the DDNS only looks at the ISP address and not the new public IP address for the VPN. The DDNS process therefore determines that no update to the public hostname is required. Assuming the public VPN IP address is of no use externally for the reasons I state above, this would seem to be an acceptable behavior for the DDNS process. If I wanted to continue initiate connections with my computer around the VPN through the ISP address, I assume I could implement routing rules, but I am not going to attempt that.

4) Firewall Protection
I dumped the iptables with and without the Firewall Protection option in the GUI, and I believe the only differences in the iptables output were the addition of these rules:
Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  209 28960 ACCEPT     0    --  *      tun1    0.0.0.0/0            0.0.0.0/0   
  102  8565 ACCEPT     0    --  tun1   *       0.0.0.0/0            0.0.0.0/0   


Not sure what these mean, but I assume these rules ensure that no traffic can go in our come out except through the VPN?

5) Other misc info for Cyberghost users:
Per previous suggestions from eibgrad and others, I ended up deleting all of the Additional Config commands in the openvpn setup GUI. After I figured out the ipv6 problem, I had no problems connecting, and agree with the "less is better" suggestion.

The bottom line:
Perhaps I am asking for too much flexibility in my setup or I have too many wrong assumptions above, but I no longer think that initiating the VPN from the router to get protection for my whole LAN is worth this hassle assuming I still want to initiate connections from the WAN side. The Cyberghost service with the app has been pretty good so far, so I am going to continue to just use it from the app on individual computers.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum