summary: Smells like progress! If I'm guessing correctly, the `route` changes imposed by connecting to the F5VPN[3] are conflicting with my server/jumpbox's current `iptables` (through which my client seeks to tunnel[7]. Does that claim seem warranted? If so, how to fix the server firewall?
details: Matt Ventura Wed, 21 Jan 2015 09:58:38 -0800 [1] >>>> First thing to check would be the routing table while the VPN is active. Tom Roche Wed, 21 Jan 2015 16:33:43 -0500 [2] >>> The `route -n` for while the OpenVPN connection is active is here[3], >>> which is part of a longer section[4] with "all the gory details" ... Matt Ventura Wed, 21 Jan 2015 22:18:57 -0800 [5] >> I meant the routing table when the F5 VPN is active, when the connectivity >> breaks. The bad news is, I should have realized that :-) The good news is, that seems quite revealing, esp in the now-upgraded context of the revised connectivity-debugging scenario[3] (which I also reran to verify results): connecting to the F5VPN (after logging into the remote-access website) creates an interface=ppp0 and extensively rewrites the routing table! https://bitbucket.org/tlroche/linode_jumpbox_config/downloads/client_networking_investigation.txt > ### 4. After connecting to F5VPN (requires login to remote-access website) ... > me@client:~$ date ; sudo route -n > Thu Jan 22 11:48:48 EST 2015 > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 0.0.0.0 10.144.15.100 128.0.0.0 UG 1 0 0 ppp0 > 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 > 10.144.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 > 128.0.0.0 10.144.15.100 128.0.0.0 UG 1 0 0 ppp0 > 134.67.15.30 10.8.0.5 255.255.255.255 UGH 1 0 0 tun0 So now I'm guessing that: 1. (from `whois 134.67.15.30`) 134.67.15.30 is the agency's VPN server. 2. I need to reconcile the above `route`ing with my server's current firewall config[6]: https://bitbucket.org/tlroche/linode_jumpbox_config/downloads/server_iptables_L.txt > Chain INPUT (policy ACCEPT) > target prot opt source destination > fail2ban-ssh tcp -- anywhere anywhere multiport > dports ssh > ACCEPT all -- anywhere anywhere > ACCEPT all -- anywhere anywhere > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED > ACCEPT all -- 10.8.0.0/24 anywhere > REJECT all -- anywhere anywhere reject-with > icmp-port-unreachable > ACCEPT all -- anywhere anywhere > ACCEPT all -- anywhere anywhere > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > Chain fail2ban-ssh (1 references) > target prot opt source destination > DROP all -- 222.186.34.202 anywhere > RETURN all -- anywhere anywhere So my questions are: 1. Am I guessing correctly? 2. If so, how to reconcile the `route`ing change imposed by the F5VPN with my server's current firewall config[6]? Thanks again for your prompt assistance, Tom Roche <tom_ro...@pobox.com> [1]: https://lists.debian.org/debian-user/2015/01/msg00733.html [2]: https://lists.debian.org/debian-user/2015/01/msg00744.html [3]: https://bitbucket.org/tlroche/linode_jumpbox_config/downloads/client_networking_investigation.txt [4]: https://bitbucket.org/tlroche/linode_jumpbox_config/wiki/OpenVPN_install#rst-header-dns-problem [5]: https://lists.debian.org/debian-user/2015/01/msg00761.html [6]: https://bitbucket.org/tlroche/linode_jumpbox_config/downloads/server_iptables_L.txt [7]: https://bitbucket.org/tlroche/linode_jumpbox_config/wiki/Home#rst-header-intended-solution -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppa6socq....@pobox.com