Hi Folks

I am trying to setup an IPSEC tunnel to a remote Contivity but keep
getting the message "Host not Responding". I fully tested the
contivity before I sent it to the remote site and everything was
working.

I suspect the ISP is blocking the IPSEC traffic. Is there any way I
can prove this? IPSEC uses protocol 50 (ESP) and 51 (AH). Is it
possible to do a traceroute or something similar with the protocol 50
or 51 set in the ip protocol field of the ip header.

Does anyone know a way I can check this?

Thanks

Report this post to a moderator

You need udp/500 as well for ISAKMP to establish the security SA's

Roland

"Ian Blaney" <Isblaney@aol.comXX> wrote in message
news:3e106479.95753557@news.easynews.com...
> Hi Folks
>
> I am trying to setup an IPSEC tunnel to a remote Contivity but keep
> getting the message "Host not Responding". I fully tested the
> contivity before I sent it to the remote site and everything was
> working.
>
> I suspect the ISP is blocking the IPSEC traffic. Is there any way I
> can prove this? IPSEC uses protocol 50 (ESP) and 51 (AH). Is it
> possible to do a traceroute or something similar with the protocol 50
> or 51 set in the ip protocol field of the ip header.
>
> Does anyone know a way I can check this?
>
> Thanks
>
>

Report this post to a moderator

Hi Roland

Thanks for the info but I was aware of this. I'm sure UDP/500 is
opened although I need to test it with NMAP or something.

Its the ESP and AH that I'm think are being blocked. I'm looking for
some way to check this. Having a quick look at the documentation of
NMAP I don't think it can scan using other IP protocols. Its limited
to ICMP, TCP and UDP.

Do you have any idea how I can check ESP and AH are opened.

Regards
Ian Blaney
On Fri, 3 Jan 2003 09:42:46 +0100, "Roland Sonder"
<roland_sonder@bluewin.ch> wrote:

>You need udp/500 as well for ISAKMP to establish the security SA's
>
>Roland
>
>"Ian Blaney" <Isblaney@aol.comXX> wrote in message
>news:3e106479.95753557@news.easynews.com...
>> Hi Folks
>>
>> I am trying to setup an IPSEC tunnel to a remote Contivity but keep
>> getting the message "Host not Responding". I fully tested the
>> contivity before I sent it to the remote site and everything was
>> working.
>>
>> I suspect the ISP is blocking the IPSEC traffic. Is there any way I
>> can prove this? IPSEC uses protocol 50 (ESP) and 51 (AH). Is it
>> possible to do a traceroute or something similar with the protocol 50
>> or 51 set in the ip protocol field of the ip header.
>>
>> Does anyone know a way I can check this?
>>
>> Thanks
>>
>>
>
>

Report this post to a moderator

why not call and ask the ISP???

or look in the log of the client

or look in the log of the FW that is in front of your concentrator

or look in the log of the concentrator??


"Ian Blaney" <Isblaney@aol.comXX> wrote in message
news:3e15771e.385258@news.easynews.com...
> Hi Roland
>
> Thanks for the info but I was aware of this. I'm sure UDP/500 is
> opened although I need to test it with NMAP or something.
>
> Its the ESP and AH that I'm think are being blocked. I'm looking for
> some way to check this. Having a quick look at the documentation of
> NMAP I don't think it can scan using other IP protocols. Its limited
> to ICMP, TCP and UDP.
>
> Do you have any idea how I can check ESP and AH are opened.
>
> Regards
> Ian Blaney
> On Fri, 3 Jan 2003 09:42:46 +0100, "Roland Sonder"
> <roland_sonder@bluewin.ch> wrote:
>
> >You need udp/500 as well for ISAKMP to establish the security SA's
> >
> >Roland
> >
> >"Ian Blaney" <Isblaney@aol.comXX> wrote in message
> >news:3e106479.95753557@news.easynews.com...
> >> Hi Folks
> >>
> >> I am trying to setup an IPSEC tunnel to a remote Contivity but keep
> >> getting the message "Host not Responding". I fully tested the
> >> contivity before I sent it to the remote site and everything was
> >> working.
> >>
> >> I suspect the ISP is blocking the IPSEC traffic. Is there any way I
> >> can prove this? IPSEC uses protocol 50 (ESP) and 51 (AH). Is it
> >> possible to do a traceroute or something similar with the protocol 50
> >> or 51 set in the ip protocol field of the ip header.
> >>
> >> Does anyone know a way I can check this?
> >>
> >> Thanks
> >>
> >>
> >
> >
>

Report this post to a moderator

Hi

The ISP claim it is not blocked but I don't think they fully
understand how IPSEC works. The last message I received from them is
that all ports are opened. ESP and AH do not use the concept of ports.
I think they are thinking in terms of TCP and UDP. I have tried to
explain this to them.

When you say client I presume you mean the remote end. I do not have
any access to the remote. I try to create a IPSEC control tunnel to
the device but no answer.

From the firewall I see packets going out but nothing coming back.

The concatenator always gives me the same message "Remote host not
responding"


On Fri, 03 Jan 2003 20:40:08 GMT, "Wow" <nickcolo@nospam.yahoo.com>
wrote:

>why not call and ask the ISP???
>
>or look in the log of the client
>
>or look in the log of the FW that is in front of your concentrator
>
>or look in the log of the concentrator??
>
>
>"Ian Blaney" <Isblaney@aol.comXX> wrote in message
>news:3e15771e.385258@news.easynews.com...
>> Hi Roland
>>
>> Thanks for the info but I was aware of this. I'm sure UDP/500 is
>> opened although I need to test it with NMAP or something.
>>
>> Its the ESP and AH that I'm think are being blocked. I'm looking for
>> some way to check this. Having a quick look at the documentation of
>> NMAP I don't think it can scan using other IP protocols. Its limited
>> to ICMP, TCP and UDP.
>>
>> Do you have any idea how I can check ESP and AH are opened.
>>
>> Regards
>> Ian Blaney
>> On Fri, 3 Jan 2003 09:42:46 +0100, "Roland Sonder"
>> <roland_sonder@bluewin.ch> wrote:
>>
>> >You need udp/500 as well for ISAKMP to establish the security SA's
>> >
>> >Roland
>> >
>> >"Ian Blaney" <Isblaney@aol.comXX> wrote in message
>> >news:3e106479.95753557@news.easynews.com...
>> >> Hi Folks
>> >>
>> >> I am trying to setup an IPSEC tunnel to a remote Contivity but keep
>> >> getting the message "Host not Responding". I fully tested the
>> >> contivity before I sent it to the remote site and everything was
>> >> working.
>> >>
>> >> I suspect the ISP is blocking the IPSEC traffic. Is there any way I
>> >> can prove this? IPSEC uses protocol 50 (ESP) and 51 (AH). Is it
>> >> possible to do a traceroute or something similar with the protocol 50
>> >> or 51 set in the ip protocol field of the ip header.
>> >>
>> >> Does anyone know a way I can check this?
>> >>
>> >> Thanks
>> >>
>> >>
>> >
>> >
>>
>
>

Report this post to a moderator

Ian Blaney wrote in message <3e161e62.880293@news.easynews.com>...
>Hi
>
>The ISP claim it is not blocked but I don't think they fully
>understand how IPSEC works.

Someone probably in the path is blocking ICMP and as a result the
2 devices cannot negotiate proper MTU. Or another more common
one we see from time to time is faults in serial lines, where the
packets get truncated going through them. For example recently
we had a Mexican ISP/Telephone company that was doing this -
they were running an ATM-to-Frame interwork with incorrect
policing setup on the ATM switch and no CDTV setup correctly
and even normal frame endpoints were sending too fast, the solution
was putting frame traffic shaping on the endpoints. (because the
Telco/ISP didn't know what the hell they were doing)

--
Ted Mittelstaedt tedm@toybox.placo.com
Author of: The FreeBSD Corporate Networker's Guide
Book website: http://www.freebsd-corp-net-guide.com

Report this post to a moderator

The following debug commands will tell you more of what's going on or wrong.
It's best to log the output to the buffer, monitor or even better to a
syslog server.

logg on
logging timestamp
logg buffer debugg
logging trap debugging
logging host inside x.x.x.x
---
debug crypto ipsec
debug crypto isakmp
---
show crypto isakmp sa
show crypto ipsec sa
show crypto engine

Roland


"Ted Mittelstaedt" <tedm@toybox.placo.com> wrote in message
news:newscache$4lp68h$jfr$1@ne
ws.ipinc.net...
> Ian Blaney wrote in message <3e161e62.880293@news.easynews.com>...
> >Hi
> >
> >The ISP claim it is not blocked but I don't think they fully
> >understand how IPSEC works.
>
> Someone probably in the path is blocking ICMP and as a result the
> 2 devices cannot negotiate proper MTU. Or another more common
> one we see from time to time is faults in serial lines, where the
> packets get truncated going through them. For example recently
> we had a Mexican ISP/Telephone company that was doing this -
> they were running an ATM-to-Frame interwork with incorrect
> policing setup on the ATM switch and no CDTV setup correctly
> and even normal frame endpoints were sending too fast, the solution
> was putting frame traffic shaping on the endpoints. (because the
> Telco/ISP didn't know what the hell they were doing)
>
> --
> Ted Mittelstaedt tedm@toybox.placo.com
> Author of: The FreeBSD Corporate Networker's Guide
> Book website: http://www.freebsd-corp-net-guide.com
>
>
>
>

Report this post to a moderator

Those are great if layer 2 is good, they are good for
troubleshooting differing manufacturers ideas of
how to speak IPSec.

But if layer 2 is bad, then you won't get anything
conclusive from the logs.

In this case the original poster stated that he got
the IPSec tunnel up and running BEFORE shipping
off one side of it to the remote site. That to me
points clearly at a failure of the transport in between the
two points, not a difference of opinion between both
endpoints as to how to speak IPSec.

--
Ted Mittelstaedt tedm@toybox.placo.com
Author of: The FreeBSD Corporate Networker's Guide
Book website: http://www.freebsd-corp-net-guide.com

Roland Sonder wrote in message <3e17863d_2@news.bluewin.ch>...
>The following debug commands will tell you more of what's going on or
wrong.
>It's best to log the output to the buffer, monitor or even better to a
>syslog server.
>
>logg on
>logging timestamp
>logg buffer debugg
>logging trap debugging
>logging host inside x.x.x.x
>---
>debug crypto ipsec
>debug crypto isakmp
>---
>show crypto isakmp sa
>show crypto ipsec sa
>show crypto engine
>
>Roland
>
>
>"Ted Mittelstaedt" <tedm@toybox.placo.com> wrote in message
> news:newscache$4lp68h$jfr$1@ne
ws.ipinc.net...
>> Ian Blaney wrote in message <3e161e62.880293@news.easynews.com>...
>> >Hi
>> >
>> >The ISP claim it is not blocked but I don't think they fully
>> >understand how IPSEC works.
>>
>> Someone probably in the path is blocking ICMP and as a result the
>> 2 devices cannot negotiate proper MTU. Or another more common
>> one we see from time to time is faults in serial lines, where the
>> packets get truncated going through them. For example recently
>> we had a Mexican ISP/Telephone company that was doing this -
>> they were running an ATM-to-Frame interwork with incorrect
>> policing setup on the ATM switch and no CDTV setup correctly
>> and even normal frame endpoints were sending too fast, the solution
>> was putting frame traffic shaping on the endpoints. (because the
>> Telco/ISP didn't know what the hell they were doing)
>>
>> --
>> Ted Mittelstaedt tedm@toybox.placo.com
>> Author of: The FreeBSD Corporate Networker's Guide
>> Book website: http://www.freebsd-corp-net-guide.com
>>
>>
>>
>>
>
>

Report this post to a moderator