Re: Problem setting up poptop on RHEL5

Sorry, I should possibly have been a little clearer. In my packet dump, 
that was the 'strange behaviour' I was seeing, where the client was 
connecting to .174 and the GRE packets were coming from 170 instead of 
the IP the client had connected to.

I guess I was asking if there was a way to specify the source IP for the 
GRE packets. The listen directive just appears to bind the listening tcp 
port, not the source of the GRE packets - for example, when not 
specified, we get

tcp        0      0 0.0.0.0:1723                0.0.0.0:* 
     LISTEN

meaning 'bind to all interfaces' and when specified we get

tcp        0      0 74.53.155.174:1723          0.0.0.0:* 
     LISTEN

However, when trying to establish a pptp tunnel, the GRE still 
originates from .170 instead of .174.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:17:31.694244 IP 74.53.155.170 > 143.238.235.209: GREv1, call 53011, 
seq 0, length 41: LCP, Conf-Request (0x01), id 1, length 27
20:17:31.911730 IP 143.238.235.209 > 74.53.155.174: GREv1, call 0, seq 
0, length 37: LCP, Conf-Request (0x01), id 0, length 23
20:17:33.907590 IP 143.238.235.209 > 74.53.155.174: GREv1, call 0, seq 
1, length 37: LCP, Conf-Request (0x01), id 1, length 23

 From looking at the ip_gre.c module in the linux kernel source, there 
appears to be an option to set the outbound source IP, I'm just 
wondering if this was actually implemented or if it simply fell back to 
the default 'use the primary IP regardless of whether its the right one 
or not'

(and then there is the weird problem that if I actually bind/connect to 
.170 I get the "GRE: xmit failed from decaps_hdlc: Operation not 
permitted " error which seems to indicate a problem with IP Tables but I 
_really_ have no idea why that is as I've expressly allowed everything 
from protocol (yes, I made sure I used the -p directive) 47 both inbound 
and outbound to every interface on the box (0/0) and it still seems to 
think I'm blocking it ??? wtf ?)

I'm going to try the passive option first and see if that makes any 
difference (binding to both .170 and .174) and then try a reboot incase 
some patch somewhere has screwed with something and needs to be reset.

Otherwise, I'm still a little lost :-)

one really weird thing, last night I was playing about with it and 
decided to shut down OpenVPN that was also running bound to the .174 
interface (uses tap devices and a different port so wouldn't have 
expected it to interfere) and all of a sudden things worked to both .170 
and then .174, I was about to post saying this had worked (I had the NAT 
device passing all inbound GRE to my windows box used to establish the 
VPN) when it suddenly reverted back to the old behaviour for no apparent 
reason.

Very weird.

-- 
Steve.


On 31/08/2011 6:29 PM, James Cameron wrote:
> On Wed, Aug 31, 2011 at 04:44:05PM +1000, Steve Phillips wrote:
>> [root@wibble ppp]# tcpdump -i eth0:3 -n proto 47
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth0:3, link-type EN10MB (Ethernet), capture size 96 bytes
>> 01:26:43.754157 IP 74.53.155.170>  143.238.235.209: GREv1, call
>> 45139, seq 0, length 36: LCP, Conf-Request (0x01), id 1, length 22
>> 01:26:43.956930 IP 143.238.235.209>  74.53.155.174: GREv1, call
>> 1536, seq 0, length 40: LCP, Conf-Request (0x01), id 1, length 26
>
> The interesting thing above is that the pptpd transmits from .170, and
> the client packets are sent to .174.
>
> There's no indication that the client packets are in response to the
> server packets.  So both ends are transmitting blind to start with.
>
>> 74.53.155.170 is the primary ip bound to eth0, 74.53.155.174 is
>> eth0:3 and is what the client is trying to connect to
>> ... [rewind] ...
>> option /etc/ppp/options.pptpd
>> debug
>> logwtmp
>> localip 10.101.0.1
>> remoteip 10.101.0.2-102
>
> You don't have a listen option, and so pptpd will bind to eth0 not
> eth0:3.  Try adding
>
> 	listen 74.53.155.174
>
> and restart pptpd.
>
>> Aug 31 01:26:43 wibble pppd[31310]: sent [LCP ConfReq id=0x1
>> <asyncmap 0x0>  <magic 0xd4d3a867>  <pcomp>  <accomp>]
>> Aug 31 01:26:43 wibble pptpd[31309]: GRE:
>> read(fd=7,buffer=80515e0,len=8260) from network failed: status = -1
>> error = Protocol not available
>>
>> Which people seem to say means there is a firewall blocking things.
>
> Yes, the firewall, a NAT gateway, the ISP, or the client, is refusing
> the packet on the grounds that nothing is listening on that protocol for
> packets from the address .170.  It is listening (at the time) to packets
> of protocol 47 coming from address .174.
>

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev

_______________________________________________
Poptop-server mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/poptop-server