Opened 10 months ago

Closed 10 months ago

Last modified 2 months ago

#1088 closed defect (worksforme)

VPN not working from IETF network

Reported by: fenton@… Owned by: nick@…
Priority: blocker Milestone: ietf-098
Component: network Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

I use a commercial VPN product from Disconnect (disconnect.me) and am not able to pass any traffic through the tunnel when using the IETF network. It works fine from the AT&T (cellular) network. I had been under the impression that the IETF network doesn't block much, but it seems like that may not be the case here.

I'll be here through Thursday, so if you want me to meet someone to diagnose the problem, I'd be happy to do that.

-Jim

Change history (7)

comment:1 Changed 10 months ago by llynch@…

Component: incomingnetwork
Owner: changed from < default > to nick@…
Priority: tbdblocker
Status: newassigned
Type: requestdefect

Hi Jim! (Lucy)

comment:2 Changed 10 months ago by nick@…

Hi Jim,

We shouldn't be blocking anything at all. Could you bring your laptop to the helpdesk in the terminal room so we can take a look?

Thanks!

comment:3 in reply to:  3 ; Changed 10 months ago by fenton@…

Will do; is there a particular time that the right person will be there?

On 3/27/17 2:18 PM, IETF Tickets/NOC wrote:
> #1088: VPN not working from IETF network
> ---------------------------+--------------------------------
>       Reporter:  fenton@…  |                Owner:  nick@…
>           Type:  defect    |               Status:  assigned
>       Priority:  blocker   |            Milestone:  ietf-98
>      Component:  network   |           Resolution:
>       Keywords:            |  My Current Location:
> My MAC  Address:           |                My OS:
> ---------------------------+--------------------------------
>
> Comment (by nick@…):
>
>  Hi Jim,
>
>  We shouldn't be blocking anything at all.  Could you bring your laptop to
>  the helpdesk in the terminal room so we can take a look?
>
>  Thanks!
>
> --
> Ticket URL: <https://tickets.meeting.ietf.org/ticket/1088#comment:2>
> IETF Tickets/NOC <https://tickets.meeting.ietf.org>
> IETF Meeting Tickets - NOC pages


comment:4 Changed 10 months ago by nick@…

Nope. We're there from 8AM to 8PM.

comment:5 Changed 10 months ago by jim@…

Jim,

We discussed your situation at the NOC status meeting this morning. One idea that came up was that IPSEC has a NAT traversal feature, which encapsulates in UDP if NAT is detected, and keeps it native ESP if not. In the modern world, the provider may assume that /everyone/ comes from a NATed IP and thus doesn't have a working listener for native ESP. Since the IETF network is all native public address space, and likely your AT&T path is not, that could explain the behavior. If you'd like to come to the NOC on the 40th floor and ask for Clemens Schrimpe, he'd be happy to test this theory with you.

Hope it helps!

  • Jim

comment:6 Changed 10 months ago by Clemens Schrimpe

Resolution: worksforme
Status: assignedclosed

Our suspicion was confirmed:

I temporarily NATed the source address to one of our router's addresses which triggered the NAT detection within IKE and caused the payload traffic (ESP) to be encapsulated by UDP (port 4500) → standard "NAT traversal" procedure. And the VPN worked as expected.

I recommended to have the firewall on the far end be opened for IP protocol 50 (ESP), which should solve this problem once and for all.

Temp. NAT removed again.

comment:7 Changed 2 months ago by Rick Alfvin

Milestone: ietf-98ietf-098

Milestone renamed

Note: See TracTickets for help on using tickets.