[Openswan Users] CentOS5 + Draytek 2820 pings only one way
paul at trusted-management.com
Fri Feb 15 06:49:06 EST 2013
Have you specified the following on your Centos machine?
the IP address for this host to use when transmitting a packet to the other side of this
link. Relevant only locally, the other end need not agree. This option is used to make the
gateway itself use its internal IP, which is part of the leftsubnet, to communicate to the
rightsubnet or right. Otherwise, it will use its nearest IP address, which is its public IP
address. This option is mostly used when defining subnet-subnet connections, so that the
gateways can talk to each other and the subnet at the other end, without the need to build
additional host-subnet, subnet-host and host-host tunnels.
I have not tried this with Centos, but you never know.
From: users-bounces at lists.openswan.org [mailto:users-bounces at lists.openswan.org] On Behalf Of John Crisp
Sent: 14 February 2013 22:49
To: users at lists.openswan.org
Subject: Re: [Openswan Users] CentOS5 + Draytek 2820 pings only one way
On 14/02/13 21:58, Willie Gillespie wrote:
> I didn't have time to look really closely yet, but since the IPsec SA
> is established, I would look really closely at the iptables/firewalls
> on both sides instead if things are going only one way. Doesn't seem
> to really be an IPsec problem.
Thanks for the reply. I wasn't sure if it was a problem in ipsec.conf (the IP address/routing part) or iptables, and whichever way, I am no expert in either !
> When you are pinging from your server, are you pinging from
> 192.168.99.1 or L.C.98.24?
That's tricky to answer.
It's a VPS server with a 'real' card and public IP address L.C.98.24 but it also has a 'dummy adaptor with an internal address of 192.168.99.1
When I ping, I am doing it from a ssh session in the box. SO what is my IP at that point. I guess L.C.98.24 if I am pinging 'off site'
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.99.1 Bcast:192.168.99.255 Mask:255.255.255.0
UP BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1 Link encap:Ethernet HWaddr 00:16:3C:DF:E2:DB
inet addr:L.C.98.24 Bcast:22.214.171.124 Mask:255.255.255.0
inet6 addr: fe80::216:3cff:fedf:e2db/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:29798084 errors:0 dropped:0 overruns:0 frame:0
TX packets:433044 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:1873430254 (1.7 GiB) TX bytes:41440151 (39.5 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:124540 errors:0 dropped:0 overruns:0 frame:0
TX packets:124540 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:10757535 (10.2 MiB) TX bytes:10757535 (10.2 MiB)
> e.g., does the following ping get through?
> ping -I 192.168.99.1 10.0.0.251
ping -I 192.168.99.1 10.0.0.251
PING 10.0.0.251 (10.0.0.251) from 192.168.99.1 : 56(84) bytes of data.
From 126.96.36.199 icmp_seq=2 Destination Host Unreachable
This is interesting - L.C.98.24 also thinks it is 10.0.0.1 when IPsec is up
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 1.635 ms 2.299 ms 2.294 ms
Kernel IP routing table
Destination Gateway Genmask Use Iface
188.8.131.52 * 255.255.255.0 eth1
10.0.0.0 * 255.255.255.0 eth1
192.168.99.0 * 255.255.255.0 eth0
default 184.108.40.206 0.0.0.0 eth1
PING 192.168.99.1 (192.168.99.1) 56(84) bytes of data.
64 bytes from 192.168.99.1: icmp_seq=1 ttl=63 time=53.2 ms
traceroute to 192.168.99.1 (192.168.99.1), 30 hops max, 40 byte packets
1 pc-00251.impamark.co.uk (10.0.0.251) 0.414 ms 0.416 ms 0.413 ms
2 192.168.99.1 (192.168.99.1) 53.438 ms 57.097 ms 60.522 ms
FROM 10.0.0.1 I can ssh to 192.168.99.1
FROM 192.168.99.1 I cannot ssh to 10.0.0.1
Hope that helps - let me know if I can provide more information.
Users at lists.openswan.org
Building and Integrating Virtual Private Networks with Openswan:
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This message has been scanned for viruses and
dangerous content by Trusted Management Limited, and is
believed to be clean.
More information about the Users