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

Drop all traffic when VPN disconnects

Discussion in 'Tomato Firmware' started by tido, Apr 4, 2014.

  1. tido

    tido Networkin' Nut Member

    Hi Folks,

    When the WRT54GL is running, and I start the VPN it connects great. Then I add the following firewall entry to block all traffic from br0 (LAN+WLAN) to vlan1 (WAN) interface:
    Code:
    iptables -I FORWARD -i br0 -o vlan1 -j DROP 
    When I disconnect the VPN, no web, etc. traffic gets through untill I re-establish the connection to the VPN. The issue is that when I enter the above line in the startup firewall script section, the vpn never connects. It tries but from the log it just keep reiterating the following:
    Code:
     daemon.notice openvpn[477]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    . Is there something special I must do to execute the iptables entry above in the firewall startup script section? Perhaps a delay?

    Any help is appreciated.
     
  2. lancethepants

    lancethepants Network Guru Member

    Your firewall rule is probably blocking your VPN from connecting (creating a new connection) . Its connection should be the one exception that your firewall allows.

    This is just a guess, but try the following (in this order). This could probably be made in to one firewall rule if it works.
    Code:
    iptables -I FORWARD -i br0 -o vlan1 -j DROP
    iptables -I FORWARD -i br0 -o vlan1 -p udp --dport 1194 -j ACCEPT
    
    Make sure this matches the protocol and port your vpn is using. Most likely it's fine how it is.
     
  3. tido

    tido Networkin' Nut Member

    The for the suggestion, was thinking something along the same lines. As the VPN only connects prior to entering the first iptables entry. The port the vpn uses is 443, if that makes a difference. Was wondering if it would better even better to use an iptables entry with the VPN's IP's, to specify things further?
     
  4. lancethepants

    lancethepants Network Guru Member

    Just throw in a destination IP to the rule.

    Code:
    iptables -I FORWARD -i br0 -o vlan1 -j DROP
    iptables -I FORWARD -i br0 -o vlan1 -p udp --dport 443 -d xxx.xxx.xxx.xxx -j ACCEPT
    
    Change to tcp if you're using tcp.
     
  5. tido

    tido Networkin' Nut Member

    Thanks again. The tunnel uses UDP, wouldn't TCP be more reliable though. Just curious, but I guess this is something that is setup on the providers server side. Also is there a ssh command to view the iptables entries once entered into the router?

    Code:
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    192.168.1.1     0.0.0.0         255.255.255.255 UH        0 0          0 vlan1
    67.55.0.106     192.168.1.1     255.255.255.255 UGH       0 0          0 vlan1
    192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
    192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 vlan1
    10.0.14.0       0.0.0.0         255.255.254.0   U         0 0          0 tun11
    127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
    0.0.0.0         10.0.14.1       128.0.0.0       UG        0 0          0 tun11
    128.0.0.0       10.0.14.1       128.0.0.0       UG        0 0          0 tun11
    0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 vlan1
    
    Also trying to understand the ip tables. The VPN has an address of 67.55.0.106. Then what is the tun11 interface? Is that just the NAT address? I assume from my machine everything goes to 10.0.14.0 and is then forwarded over 67.55.0.106 then out the gateway 192.168.1.1. Just a little hard to read/understand.
     
    Last edited: Apr 4, 2014
  6. lancethepants

    lancethepants Network Guru Member

    UDP is preferred for OpenVPN.

    Code:
    iptables -L -v --line-numbers
    
    This this should you everything you need to see.
     
  7. lancethepants

    lancethepants Network Guru Member

    tun11 is the name of the tun/tap device, sort of a virtual ethernet port.

    You connect to 67.55.0.106
    They assign you an IP address whose gateway is 10.0.14.0. It appears then yes, you internet is natted probably with other VPN users, doesn't look like they give you a public IP address.
    All communication between those IP addresses is going through your WAN.

    Is it working now on boot then?
     
  8. tido

    tido Networkin' Nut Member

    I'll test once back home, currently working on it remotely. Sounds promising though. How do you read the iptables so well. Are they like firewall rules, where they are read from top to bottom and once a rule matches a route the reading of the route table stops?
     
  9. lancethepants

    lancethepants Network Guru Member

    I only know enough iptables just to do what I want. Yes, the rules read from top to bottom. Your different chains (INPUT FORWARD OUTPUT, there are more though) can either be set to accept or block all as default. In the case of tomato, INPUT and FORWARD block everything by default, unless it passes one of the rules in iptables.
     
  10. tido

    tido Networkin' Nut Member

    Code:
    iptables -I FORWARD -i br0 -o vlan1 -j DROP
    iptables -I FORWARD -i br0 -o vlan1 -p udp --dport 443 -d 67.55.0.106 -j ACCEPT
    With the addition of the iptables entries (above) in the firewall or wanup script sections, the VPN does not connect.
    Code:
    Apr  4 18:14:30 WRT54GLv1-1-VPN daemon.notice openvpn[478]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    Apr  4 18:14:30 WRT54GLv1-1-VPN daemon.notice openvpn[478]: Socket Buffers: R=[32767->65534] S=[32767->65534]
    Apr  4 18:14:30 WRT54GLv1-1-VPN daemon.notice openvpn[488]: UDPv4 link local: [undef]
    Apr  4 18:14:30 WRT54GLv1-1-VPN daemon.notice openvpn[488]: UDPv4 link remote: [AF_INET]67.55.0.106:443
    Apr  4 18:14:30 WRT54GLv1-1-VPN daemon.notice openvpn[488]: TLS: Initial packet from [AF_INET]67.55.0.106:443, sid=be209eff 52ef5ab1
    Apr  4 18:14:30 WRT54GLv1-1-VPN daemon.warn openvpn[488]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: VERIFY OK: depth=1, CN=OpenVPN CA
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: VERIFY OK: nsCertType=SERVER
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: VERIFY OK: depth=0, CN=OpenVPN Server
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Apr  4 18:14:31 WRT54GLv1-1-VPN daemon.notice openvpn[488]: [OpenVPN Server] Peer Connection Initiated with [AF_INET]67.55.0.106:443
    Apr  4 18:14:34 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:14:39 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:14:44 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:14:49 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:14:54 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:14:59 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:15:04 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:15:07 WRT54GLv1-1-VPN cron.err crond[151]: time disparity of 23277494 minutes detected
    Apr  4 18:15:09 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:15:14 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:16:30 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:16:35 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.err openvpn[488]: event_wait : Interrupted system call (code=4)
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: OpenVPN STATISTICS
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Updated,Fri Apr  4 18:16:38 2014
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: TUN/TAP read bytes,0
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: TUN/TAP write bytes,0
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: TCP/UDP read bytes,9159
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: TCP/UDP write bytes,5115
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: Auth read bytes,2853
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: pre-compress bytes,0
    Apr  4 18:16:38 WRT54GLv1-1-VPN daemon.notice openvpn[488]: post-compress bytes,0
    Apr  4 18:16:40 WRT54GLv1-1-VPN daemon.err openvpn[488]: event_wait : Interrupted system call (code=4)
    Apr  4 18:16:40 WRT54GLv1-1-VPN daemon.notice openvpn[488]: SIGTERM[hard,] received, process exiting
    
    Strange thing I noticed. I then stop the attempt to connect the VPN. Connect with OpenVPN on my windows machine, then disconnect. On the router then try to connect to the VPN and it connects, bit strange there. Router still must be blocking something not letting the VPN through.
     
  11. lancethepants

    lancethepants Network Guru Member

    Perhaps try the following.

    Code:
    iptables -I FORWARD -i br0 -o vlan1 -j DROP
    iptables -I FORWARD -o vlan1 -p udp --dport 443 -d xxx.xxx.xxx.xxx -j ACCEPT
    
    '-i br0' states that the packet is being received on br0 interface. Try removing it like I've posted above, since it's not being received on br0, but rather originated from it. That might be the issue.
     
  12. tido

    tido Networkin' Nut Member

    Okay managed to get it to reconnect and drop my computers connection an another router Asus RT-N16 (main router, R1). With the following:

    Code:
    iptables -I FORWARD -i br0 -s 192.168.1.11 -o vlan2 -j DROP
    Now I'm questioning the WRT54GL (R2, VPN only) or my setup.

    R1 is set to a gateway.
    R1 connects to a switch, the switch connects to the WAN interface of R2

    R2 WAN interface receives a DHCP address from R1 (strangely I can't manage this address, only the LAN IP which is statically set)
    R2 is set as a router.
    R2 is DHCP enabled on the LAN interfaces.
     

Share This Page