[Openswan Users] can ping to road warrior, cannot ping the
other way
Joseph Commisso
commisj at cs.sunyit.edu
Fri Nov 12 17:42:16 CET 2004
Maybe I could be more clear.
I have the two LANs at the two ends of the tunnel.
I can ping from 192.168.3.7 to 192.168.3.1 (RW internal ip) through the
external ip (1.2.3.4) -----> into the static external nic (5.6.7.8)
through the static internal (192.168.192.1) and finally to 192.168.192.4,
which is my pc.
Now my pc uses a wyse 50 emulation (similar to telnet) to get from
192.168.192.4 (my pc) to 192.168.192.10, the work server. This is where
our company does it's business on. It is a SCO box with one network card
at 192.168.192.10.
So, as I was saying, I can ping from remote
RW 192.168.3.7 -> 192.168.3.1 -> 1.2.3.4 -> 5.6.7.8 -> 192.168.192.1 ->
192.168.192.4
I can also ping in the reverse.
But I can't ping the server. The server is connected with a hub that
includes 192.168.192.10, 192.168.192.4, 192.168.192.1 and more. I can ping
from 192.168.192.1 to 192.168.192.10, but I can't ping from behind the RW
tunnel through the tunnel to 192.168.192.10.
Any ideas?
TIA,
Joe Commisso
On Fri, 12 Nov 2004, Joseph Commisso wrote:
> OK, the ping works in both directions, but not to our server.
>
> I can ping back from the road warrior to the network behind our static ip
> server, BUT we have another server behind the gateway/firewall/openswan box
> that does not respond to the pings. Now, the pc that I use (192.168.192.4)
> has a network setting of "gateway = 192.168.192.1",
> which is the internal nic of our gateway/firewall/openswan box
> and I can ping to that. Our inventory server, which is the whole reason for
> the effort, does not get the ping and that seems to be the issue. It is a SCO
> box. Can I get around this without changing any SCO configurations? One more
> question: how? Thanks again. It looks like it is all down hill from here. Oh,
> by the way, I am still getting the errors below on both openswan ends, but
> the tunnel seems to be getting by even though. I guess I can tackle that
> another day?
>
> TIA,
> Joe Commisso
>
> On Thu, 11 Nov 2004, Joseph Commisso wrote:
>
>> Hi,
>>
>> I have linux 2.4 kernel with openswan 2.2.0 and the tunnel is up!
>> There are two gateway/firewalls running openswan.
>> I can ping from behind our static ip to the road warrior fine, but when I
>> ping from behind the road warrior to a box behind the static ip address, no
>> go:
>>
>> # ping -I 192.168.192.1 192.168.3.7
>> PING 192.168.3.7 (192.168.3.7) from 192.168.192.1 : 56(84) bytes of data.
>> 64 bytes from 192.168.3.7: icmp_seq=1 ttl=127 time=33.8 ms
>> 64 bytes from 192.168.3.7: icmp_seq=2 ttl=127 time=13.3 ms
>> 64 bytes from 192.168.3.7: icmp_seq=3 ttl=127 time=15.9 ms
>> 64 bytes from 192.168.3.7: icmp_seq=4 ttl=127 time=17.7 ms
>>
>> --- 192.168.3.7 ping statistics ---
>> 4 packets transmitted, 4 received, 0% packet loss, time 3032ms
>> rtt min/avg/max/mdev = 13.322/20.195/33.807/8.015 ms
>>
>> But, look at the other direction:
>>
>> # ping -I 192.168.3.1 192.168.192.10
>> PING 192.168.192.10 (192.168.192.10) from 192.168.3.1 : 56(84) bytes of
>> data.
>>
>> --- 192.168.192.10 ping statistics ---
>> 29 packets transmitted, 0 received, 100% packet loss, time 28013ms
>>
>> Also, here is the output of "ipsec verify":
>>
>> # ipsec verify
>> Checking your system to see if IPsec got installed and started correctly:
>> Version check and ipsec on-path [OK]
>> Linux Openswan cvs2002Mar11_19:19:03 (klips)
>> Checking for IPsec support in kernel [OK]
>> Checking for RSA private key (/etc/ipsec.secrets) [OK]
>> Checking that pluto is running [OK]
>> Two or more interfaces found, checking IP forwarding [OK]
>> Checking NAT and MASQUERADEing
>> Checking tun0x1006 at 24.39.245.142 from 192.168.3.0/24 to 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> [FAILED]
>> SNAT from 192.168.3.0/24 to 0.0.0.0/0 kills tunnel 192.168.3.0/24 ->
>> 192.168.192.0/24
>> Checking for 'ip' command [OK]
>> Checking for 'iptables' command [OK]
>>
>> Opportunistic Encryption DNS checks:
>> Looking for TXT in forward dns zone: george.tahan.com [MISSING]
>> Does the machine have at least one non-private address? [OK]
>> Looking for TXT in reverse dns zone: 213.43.58.24.in-addr.arpa. [MISSING]
>>
>> The other end of the tunnel gives the same output (it just has a different
>> ip that it references), but it is the exact same failure.
>>
>> The ping does work from one end, though.
>> Any suggestions would be greatly appreciated.
>>
>> TIA,
>> Joe Commisso
>> _______________________________________________
>> Users mailing list
>> Users at openswan.org
>> http://lists.openswan.org/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
>
More information about the Users
mailing list