Date: Tue, 7 May 2013 14:17:33 -0500 From: Eric van Gyzen <eric@vangyzen.net> To: Matthias Apitz <guru@unixarea.de> Cc: freebsd-net@freebsd.org, Joe Holden <lists@rewt.org.uk> Subject: Re: ppp(8) and inbound IP connections Message-ID: <5189534D.4020605@vangyzen.net> In-Reply-To: <20130507185623.GA1115@tiny.Sisis.de> References: <20130507181345.GA992@tiny.Sisis.de> <51894B52.2050903@rewt.org.uk> <20130507185623.GA1115@tiny.Sisis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/07/2013 13:56, Matthias Apitz wrote: > El día Tuesday, May 07, 2013 a las 07:43:30PM +0100, Joe Holden escribió: > >>> tun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 >>> options=80000<LINKSTATE> >>> inet 10.33.28.104 --> 10.64.64.64 netmask 0xffffffff >>> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> >>> Opened by PID 799 >>> >>> and the routing is: >>> >>> >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif Expire >>> default 10.64.64.64 UGS 0 1694 tun6 >>> 10.33.28.104 link#7 UHS 0 0 lo0 >>> 10.64.64.64 link#7 UHS 0 1 tun6 >>> 127.0.0.1 link#6 UH 0 75 lo0 >>> >>> Any ideas about this? Thanks. >>> >>> I'm attaching the ppp.conf file. >>> >>> matthias >>> >> It seems quite clear from your ifconfig output that your provider >> doesn't give you a routable address, so you will never see inbound >> connections. Usually providers have an alternate APN that will give you >> one, but that depends on the provider in question. > Ofc, the provider must NAT somehow my local addr behind some routable > valid IP addr, in our case 82.113.99.104; without this nothing would > come back, even when the 1st SYN was from my side; the question is, why > they do not manage the NAT table so any SYN to 82.113.99.104 is sent to > my ppp link; > > or if they do send it, and my ppp config is wrong? Most likely, multiple customers' local addresses are NATed to the same routable address, so the router can't know which customer to chose for a new incoming connection. De-NATing of incoming packets for existing sessions is done via per-connection state-tracking, which of course doesn't exist for a new incoming connection. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5189534D.4020605>