[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Destination unreachable (Host administratively prohibited)


  • Subject: Re: [Openvpn-users] Destination unreachable (Host administratively prohibited)
  • From: "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx>
  • Date: Tue, 13 Mar 2007 10:34:40 -0700

Bottom posted, see below.

----- Original Message ----- 
From: "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx>
To: <openvpn-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, March 12, 2007 12:46 PM
Subject: Destination unreachable (Host administratively prohibited)


> Greetings -
>
> I am trying to setup my first installation of openvpn, but have not been 
> successful yet and am struggling to figure out what is going on.  I can 
> successfully ping across the tunnel, but have been unable to establish a 
> connection.  Looking at a wireshark trace on the server I get the 
> "Destination unreachable (Host administratively prohibited)" message.  I 
> have done my research (google, OpenVPN book by Feilner, FAQ's, and the 
> HowTo) and everything seems to point to either a firewall issue or a 
> routing problem.  With my limited experience, I can't seem to pinpoint the 
> right problem/solution.  I am hoping someone can either identify and solve 
> this issue, or explain to me what additional diagnostics steps I can take 
> to figure it out.
>
> Here is what I have done.
>
> I have a simple server and client configuration.  My server is RHEL3, my 
> client is Centos 4.  My network configuration is shown below.
>
> openvpn client--->client dsl modem--->internet--->server dsl 
> modem--->network switch--->openvpn server
> 192.168.1.101--->gw 192.168.1.1--->internet--->gw 
> 192.168.112.10--->network switch--->192.168.112.1
>
> client is Centos 4
> client dsl modem (Netopia) is gateway and is issued dynamic ip by provider
> TUN is assigned 10.8.6.6
>
> server is RHEL3
> server dsl modem (Actiontec) is gateway and has static ip address
> TUN is assigned 10.8.6.1
>
> I have enabled ip forwarding on both the server and client
> echo > 1 /proc/sys/net/ipv4/ip_forward
>
> I have disabled the firewall and SE Linux on the client.  The client 
> gateway is only conducting NAT, no firewall.  Port forwarding is enabled 
> for port 1194 on the gateway.
>
> The firewall on the server lists TUN as a trusted device.  The server 
> gateway is conducting NAT, has a firewall with port forwarding enabled for 
> port 1194.
>
> The routing table for the Server is:
> [root@Bison root]# netstat -rn
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt 
> Iface
> 10.8.6.2        0.0.0.0         255.255.255.255 UH        0 0          0 
> tun0
> 10.8.6.0        10.8.6.2        255.255.255.0   UG        0 0          0 
> tun0
> 192.168.112.0   0.0.0.0         255.255.255.0   U         0 0          0 
> eth0
> 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 
> eth0
> 0.0.0.0         192.168.112.10  0.0.0.0         UG        0 0          0 
> eth0
>
> A wireshark packet capture at the server shows that a ping from the client 
> works to both the tunnel endpoint and the LAN ip address, but a client 
> connection does not:
>      4 70144.567204 10.8.6.6              10.8.6.1              ICMP Echo 
> (ping) request
>      5 70144.567288 10.8.6.1              10.8.6.6              ICMP Echo 
> (ping) reply
>      6 70145.568024 10.8.6.6              10.8.6.1              ICMP Echo 
> (ping) request
>      7 70145.568087 10.8.6.1              10.8.6.6              ICMP Echo 
> (ping) reply
>      8 70146.570730 10.8.6.6              10.8.6.1              ICMP Echo 
> (ping) request
>      9 70146.570784 10.8.6.1              10.8.6.6              ICMP Echo 
> (ping) reply
>     10 70211.525060 10.8.6.6              192.168.112.1         ICMP Echo 
> (ping) request
>     11 70211.525144 192.168.112.1         10.8.6.6              ICMP Echo 
> (ping) reply
>     12 70212.522569 10.8.6.6              192.168.112.1         ICMP Echo 
> (ping) request
>     13 70212.522625 192.168.112.1         10.8.6.6              ICMP Echo 
> (ping) reply
>     14 70213.526026 10.8.6.6              192.168.112.1         ICMP Echo 
> (ping) request
>     15 70213.526078 192.168.112.1         10.8.6.6              ICMP Echo 
> (ping) reply
>     16 70258.307654 10.8.6.6              192.168.112.1         UDP Source 
> port: 32772  Destination port: 33435
>     17 70258.307703 192.168.112.1         10.8.6.6              ICMP 
> Destination unreachable (Host administratively prohibited)
>     18 70258.659129 10.8.6.6              192.168.112.1         UDP Source 
> port: 32772  Destination port: 33436
>     19 70258.659166 192.168.112.1         10.8.6.6              ICMP 
> Destination unreachable (Host administratively prohibited)
>     20 70278.511335 10.8.6.6              10.8.6.1              UDP Source 
> port: 32773  Destination port: 33435
>     21 70278.511379 10.8.6.1              10.8.6.6              ICMP 
> Destination unreachable (Host administratively prohibited)
>     22 70278.860821 10.8.6.6              10.8.6.1              UDP Source 
> port: 32773  Destination port: 33436
>     23 70278.860862 10.8.6.1              10.8.6.6              ICMP 
> Destination unreachable (Host administratively prohibited)
>
> I think the interpretation of this is that the TUN network (10.8.6.x) is 
> not able to reach the LAN network (192.168.112.x); but why?  Thanks for 
> any help anyone can provide.  I can provide additional diagnostic 
> information if needed (e.g., routing info on gateways, vpn config files, 
> etc.).
>
>
> Jeff Boyce
> www.meridianenv.com
>
>

Date: Mon, 12 Mar 2007 21:01:51 +0100
From: Davide Bolcioni <dblistsub-openvpn@xxxxxxxx>
Subject: Re: [Openvpn-users] Destination unreachable (Host
administratively prohibited)
To: OpenVPN List <openvpn-users@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <200703122101.51839.dblistsub-openvpn@xxxxxxxx>
Content-Type: text/plain;  charset="utf-8"

On Monday 12 March 2007 20:46:52 Jeff Boyce wrote:

> The firewall on the server lists TUN as a trusted device.

A shot in the dark ... are you using Lokkit on the server ? Could you post 
the
output of iptables -n -L ? You need to trust tun+, or at least tun0, in
iptables rules.

Also ... what about tcp_wrappers, e.g. hosts.allow and hosts.deny ?

Just my ?0.02,
Davide Bolcioni
-- 
There is no place like /home.


Greetings -
Thanks for the ideas.  I think this output may teach me something.  And if 
you understand it clearly and can explain it to me, it may even solve my 
problem.  Here is my output for the three items you suggested posting.  Also 
after seeing the iptables output I looked at the file 
/etc/sysconfig/iptables and I have posted it also.  I generally set or 
change my firewall security settings using either the Gnome GUI or through 
Webmin.  The /etc/sysconfig/iptables file reflects what is shown in both of 
these GUIs.  (Why is the output of iptables -n -L different?).  Hosts allow 
and deny are both blank.

[root@Bison root]# iptables -n -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          icmp type 255
ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state 
RELATED,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0          state NEW tcp 
dpt:22
REJECT     all  --  0.0.0.0/0            0.0.0.0/0          reject-with 
icmp-host-prohibited

/etc/sysconfig/iptables
# Firewall configuration written by redhat-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -j ACCEPT
-A RH-Firewall-1-INPUT -i tun0 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j 
ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT


/etc/hosts.allow
#
# hosts.allow	This file describes the names of the hosts which are
#		allowed to use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
#

/etc/hosts.deny
#
# hosts.deny	This file describes the names of the hosts which are
#		*not* allowed to use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!





______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users