Re: network newbie seeks assistance debugging iptables for VPN tunnel
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_Roche@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
Reply to: