On 1/22/2015 9:43 AM, Tom Roche wrote:
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
I'm assuming ppp0 is the F5 VPN interface. Try deleting the first entry
in the routing table after bringing up the F5 VPN
(something like 'route del default ppp0' if memory serves) and see if it
fixes the problem.
This will probably break connectivity to the VPN until you restart it,
but see if you can access the internet in general.
Also, another option would be to simply run the F5 VPN client on the
linode.
Matt Ventura
--
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/54c1485e.2060...@mattventura.net