1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

Open VPN Kill Switch Upon VPN Reconnect

Discussion in 'Asuswrt-Merlin' started by Atreides Modi, Aug 20, 2019.

  1. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    Assumption: Kill Switch will block traffic until such time as OpenVPN connection is re-established.

    Situation: Have the following configuration for OpenVPN Client on RT_AC3100 with 384.13_0:
    • Connection Retry attempts set to "-1"
    • Force Internet traffic through tunnel set to "Policy Rules"
    • Block routed clients if tunnel goes down set to "Yes"
    • Internal FireTV device added with destination 0.0.0.0 and iface to "VPN"
    • Custom configuration set to
      • resolv-retry infinite
      • persist-remote-ip
      • verify-x509-name us2.vyprvpn.com name
      • keepalive 10 60
      • tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
    VPN Client runs like a champ. Until, it appears, I have an ISP disconnect and/or remote VPN server disconnect, which drops the connection and triggers the kill switch for FireTV.

    When the router re-establishes internet connection, the OpenVPN client does properly reconnect as evidenced by VPN Status tab. So far so good. EXCEPT; the FireTV remains blocked, presumably by the kill switch (e.g. Ethernet connected, but no Internet connection).

    Restarting OpenVPN Client immediately reinstates the FireTV internet connection through tunnel. Ideas?
     
  2. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,298
    Location:
    UK
    If the KILL-switch is currently ACTIVE for a VPN Client, then 'prohibit' will appear in the appropriate Selective routing table:
    Code:
    for i in 1 2 3 4 5;do echo -en "VPN Client $i: ";ip route show table 11$i | grep -E "^default|prohibit";echo;done
    
    ip rule
    However, if the KILL-switch is NOT in force for the VPN connection, if the nominated VPN device still cannot seemingly utilise the tunnel, then either DNS is unavailable - particularly likely if 'Accept DNS Configuration=EXCLUSIVE' and/or the tunnel is unable to actually pass data.

    In the case of an unexpected WAN restart, a modified nat-start script can easily check if the VPN status is marked as currently UP, and can subsequently explicitly restart the VPN client.

    Alternatively, you could deploy a proactive VPN monitoring script e.g. VPN Failover
     
    amplatfus likes this.
  3. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    Unrelated to the kill switch issue, have an OpenVPN related question...

    Noticing that Adaptive QOS
    Thanks for this helpful response. As an FYI, I have "Accept DNS Configure=Disabled". With this advice, I will share my test findings and resolution.
     
  4. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    Wondering if I even need the "Block routed clients if tunnel goes down" enabled, since setting "Force Internet traffic through tunnel" to Policy (Strict) which appears to block traffic when the connection is down and resumes properly when link is back up. Maybe I am misunderstanding something, but it doesn't appear to exhibit any traffic leakage.
     
  5. Martineau

    Martineau Part of the Furniture

    Joined:
    Jul 8, 2012
    Messages:
    2,298
    Location:
    UK
    If you enable 'Block routed clients if tunnel goes down', then during the boot process the WAN blocking rule is immediately in effect for the associated Selective Routing VPN Client devices.

    So if you never actually start the VPN Client, or manually terminate the VPN Client (either via the GUI or via a 'service stop_vpnclientX' command) then the defined VPN only devices will actually use the WAN.
     
  6. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    So a little more testing with the above configuration ("Block routed clients if tunnel goes down" disabled and "Force internet traffic through tunnel" set to Policy. When the networked client looses its connection through the tunnel (e.g. curl ifconfig.me), I can still see the tunnel working from the router (e.g. curl ifconfig.me --interface tun11).

    Before and after ip route show table 1 returns no results. Unsure what to look at to pin down what's causes the route to break. Not seeing anything in the logs. So where could I look to figure out why with "Block routed clients(...)" disabled and tun11 working that the client would be blocked.

    UPDATE - Did a bunch of cleaning / updated / installing (x3mrouting, connmon, scribe) / restarts and so far the connection has remained up. I'll continue to monitor and if things go awry again I will share some more detailed logs / config info. Thanks @Martineau)
     
    Last edited: Aug 31, 2019
  7. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    Okay, I did some log compares of when the tunnel goes down due to keepalive 10 60 issuing a SIGUSR1 versus when it is restart manually triggered producing a SIGTERM. The only difference I see is in where the below ERROR BLOCK occurs:

    ERROR BLOCK
    COMMON (1) TO SIGUSR1 and SIGTERM
    COMMON (2) TO SIGUSR1 and SIGTERM
    The SIGUSR1 event sequence is COMMON (1) -> ERROR BLOCK -> COMMON (2) and the SIGTERM event sequence is ERROR BLOCK -> restart of openvpn -> COMMON (1) -> COMMON (2). Hope this makes sense. Note that public IP has been obscured with X.X.X.X.

    Here's the route:
     
    Last edited: Aug 31, 2019
  8. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    On closer examination, I think this is key to the SIGUSR1 failure:
    Though later on there occurs:
    The SIGTERM sequence is followed by
    Seems closing the interface doesn't achieve reopening the TUN/TAP device objective which the restart of OpenVPN achieves... Guessing one of the client settings is tied to this, perhaps one of the persist- directives force having to restart OpenVPN? Is there a way (without new script installs) to force a SIGTERM wherever SIGUSR1 occurs?
     
    Last edited: Aug 31, 2019
  9. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    After much analysis, which is complicated by fact that the timing of failure was not easy to time (random), I identified that SIGUSR1 process, the following route is lost / not-recreated:

    iptables --line -t nat -nvL
    All other route views are identical before and after:
    Thoughts?
     
  10. Atreides Modi

    Atreides Modi Occasional Visitor

    Joined:
    Aug 11, 2015
    Messages:
    11
    Update Sep 6 2019 - Things have been working, though I unfortunately am unsure why / what root cause was. So, won't consider it solved until I've got a week of uptime without failure.

    Update Sep 10 2019 - Nope - it has been more resilient, but it failed this morning with same situation - the MASQUERADE route for tun11 gets dropped. Back to the drawing board.
    For now, since this seems like a bandaid to a root cause I've yet to find, I added the below to my /jffs/scripts/nat-start script:
     
    Last edited: Sep 10, 2019