1

After just having succesfully configured my VPN server to connect my VPN clients to my LAN ( Expose internal LAN to VPN using CentOS FirewallD ) I find that pinging is the only thing that works. I can't reach any machine that I can ping over SSH, HTTP, FTP, or other services.

Some background info:

On the server: The machine is a CentOS 7 install that runs Tinc VPN.

 #firewall-cmd --get-active-zones 
internal
  interfaces: eth0 (192.168.178.0/24)
external
  interfaces: vpn (10.0.0.0/24)

The client is a Fedora 21 machine that connects to the VPN server from varying locations (3G for example).

[root@chlorine hosts]# ssh 192.168.178.21
ssh: connect to host 192.168.178.21 port 22: No route to host
[root@chlorine hosts]# wget 192.168.178.21
--2015-01-06 00:52:50--  http://192.168.178.21/
Connecting to 192.168.178.21:80... failed: No route to host.
[root@chlorine hosts]# ping 192.168.178.21
PING 192.168.178.21 (192.168.178.21) 56(84) bytes of data.
64 bytes from 192.168.178.21: icmp_seq=1 ttl=63 time=119 ms
64 bytes from 192.168.178.21: icmp_seq=2 ttl=63 time=135 ms

Ping to any machine works. LAN machines can also ping VPN machines just fine. Anything other than ping however, fails. Does not seem to be a firewall issue at least on either clients sides. Does anyone have a clue? Things I could try?

PS: Traceroute from the VPN client to a LAN host and the vpn server's lan port: 

    [alex@chlorine ~]$ traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  10.0.0.60 (10.0.0.60)  128.311 ms  130.495 ms  182.502 ms
 2  10.0.0.60 (10.0.0.60)  184.198 ms !X  188.066 ms !X  190.507 ms !X

    [alex@chlorine ~]$ traceroute 192.168.178.47
traceroute to 192.168.178.47 (192.168.178.47), 30 hops max, 60 byte packets
 1  192.168.178.47 (192.168.178.47)  127.881 ms !X  129.314 ms !X  133.072 ms !X

The "!X" in the traceroute seems to mean "Communication Administratively Prohibited", which seems to imply firewall issues, however on I've disabled/opened the firewalls everywhere as much as possible to rule it out:

VPN server: 

[root@zinc ~]# firewall-cmd --list-ports --zone=external
1024-65535/tcp 1024-65535/udp
[root@zinc ~]# firewall-cmd --list-ports --zone=internal
1024-65535/tcp 1024-65535/udp 656/udp 655/tcp 655/udp 656/tcp

I've been trying to reach a Windows box that has its firewalls completely disabled at 192.168.178.37, however with the same results as every other LAN machine; Ping works, the rest does not, traceroute says "Communication Administratively Prohibited." Any more ideas? Thanks for the help so far! This is strange and hard to diagnose properly for me.

Improve this question
6
  • 1
    Are you sure it's not the firewall? Could you show us the firewall rules of one of the hosts in question?
    – Katherine Villyard
    Jan 6, 2015 at 0:01
  • It doesn't matter which host I try, even if I try reach a Windows host with disabled firewall I can only ping, not RDP, SSH, or reach the running HTTP server. @KatherineVillyard
    – Alex
    Jan 6, 2015 at 0:10
  • Does traceroute say anything interesting?
    – Katherine Villyard
    Jan 6, 2015 at 0:17
  • I added the traceroute to the post. As a new thing, I can now SSH to the LAN port of the VPN server, but still not to other hosts in the same LAN. Ping still works everywhere.
    – Alex
    Jan 6, 2015 at 0:30
  • 1
    I just noticed the !X in the traceroute, apparently it means "Communication administratively prohibited" or something? serverfault.com/questions/434211/… Maybe that has something to do with it...
    – Alex
    Jan 6, 2015 at 0:35

1 Answer 1

Reset to default
2 
[alex@chlorine ~]$ traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  10.0.0.60 (10.0.0.60)  128.311 ms  130.495 ms  182.502 ms
 2  10.0.0.60 (10.0.0.60)  184.198 ms !X  188.066 ms !X  190.507 ms !X

!X does indeed mean "administratively prohibited." Check for firewall rules on the VPN server and the router which may be blocking traffic.

Improve this answer
2
  • 1
    It's definitely not the source client, the VPN server, or the target host, so the only place I can imagine it to be is the Fritzbox ADSL router that I did manage to get the route added to, but probably has some firewall running that doesn't like it. I still haven't been able to solve it, I'm going to try see if I can rule out the fritzbox too, I'll get back here if I manage to find a way around it. Thanks for the help so far though!
    – Alex
    Jan 6, 2015 at 2:07
  • 1
    Wouldn't you see the "!X" only if the machine was aware that the route is prohibited? If the machine is aware of a rule such as this, it's likely a problem you can find and resolve on that machine where you pulled your trace-route from. Generally something like this is called "NAT Traversal" and a LOT of applications, firewalls, etc turn this off by default to prevent security issues. The reason ICMP could be working is that ICMP generally has NAT Traversal allowed by default. TLDR: Check for NAT Traversal restrictions on your firewall rules.
    – IceMage
    Jan 8, 2015 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .