Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've tried to look elsewhere on this site but I couldn't find anything matching this problem. Right now I have an ipsec tunnel open between our local network and a remote network.

Currently, the local box running Openswan ipsec with the tunnel open can ping the remote ipsec box and any of the other computers in the remote network. When logged into on of the remote computers, I can ping any box in our local network. That's what works, this is what doesn't:

I can't ping any of the remote computers via a local machine that is not the ipsec box.

Here's a diagram of our network:

[local ipsec box] ----------\
                             \
[arbitrary local computer] --[local gateway/router] -- [internet] -- [remote ipsec box] -- [arbitrary remote computer]

The local ipsec box and the arbitrary local computer have no direct contact, instead they communicate through the gateway/router. The router has been set up to forward requests from local computers for the remote subnet to the ipsec box. This works.

The problem is the ipsec box doesn't forward anything.

Whenever an arbitrary local computer pings something on the remote subnet, this is the response:

[user@localhost ~]# ping 172.16.53.12
PING 172.16.53.12 (172.16.53.12) 56(84) bytes of data.
From 10.31.14.16 icmp_seq=1 Destination Host Prohibited
From 10.31.14.16 icmp_seq=2 Destination Host Prohibited
From 10.31.14.16 icmp_seq=3 Destination Host Prohibited

Here's the traceroute:

[root@localhost ~]# traceroute 172.16.53.12
traceroute to 172.16.53.12 (172.16.53.12), 30 hops max, 60 byte packets
 1  router.address.net (10.31.14.1)  0.374 ms  0.566 ms  0.651 ms
 2  10.31.14.16 (10.31.14.16)  2.068 ms  2.081 ms  2.100 ms
 3  10.31.14.16 (10.31.14.16)  2.132 ms !X  2.272 ms !X  2.312 ms !X

That's the IP for our ipsec box it's reaching, but it's not being forwarded.

On the IPSec box I have enabled IP Forwarding in /etc/sysctl.conf net.ipv4.ip_forward = 1

And I have tried to set up IPTables to forward:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [759:71213]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 4500 -j ACCEPT
-A INPUT -m policy --dir in --pol ipsec -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -s 10.31.14.0/24 -d 172.16.53.0/24 -j ACCEPT
-A FORWARD -m policy --dir in --pol ipsec -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Am I missing a rule in IPTables? Is there something I forgot?

NOTE: All the machines are running CentOS 6.x Edit: Note 2: eth1 is the only network interface on the local ipsec box.

share|improve this question
    
The firewall looks fine, but I would try removing the --reject-with icmp-host-prohibited entries (one at a time) to confirm whether it is the firewall or not. –  mgorven Mar 26 '12 at 23:44

1 Answer 1

After looking around and following your suggestions, I decided to re-think my approach a minute and noticed a very painful mistake. 172.16.53.0/24 is supposed to be 172.16.53.0/28. Works like a charm now. Moral of the story: make sure you have your subnet addresses right, folks!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.