Re: OpenBSD 3.3 and MS PPTP

[Keith McDuffee <gudlyf@realistek.com>]

Alright, I've done a bit of testing with tcpdump on the interfaces and 
pflog, and here's what I'm running into.  When I try to connect to the 
PPTP server, tcpdump on $ext_if shows the packets on port 1723 just 
fine, going back and forth.  The gre packets however are only shown 
coming in from the client -- no packets going out on $ext_if from the 
server or any other system on the LAN for that matter.

If I tcpdump on $int_if, I see the packets coming in from the client AND 
trying to go out from the server.

I set all passed incoming and outgoing packets for gre to be logged. 
Doing a tcpdump of pflog shows gre packets are seen by the filter and 
are being passed.

So my question now is, where the heck are the packets from the server 
going to once they hit $int_if?  They come in to $int_if, the filter 
sees them and passes them, and they never make it out of $ext_if.  What 
am I missing?

I've sucessfully patched pf.c to version 3.238.2.1 (for the gre fix).  I 
have sysctl -w net.inet.gre.allow = 1.  I did not compile the kernel 
without gre support (so pseudo-device gre0 still exists but is not 
configured -- I was told this was not necessary).  I have an ip alias on 
$ext_if for the PPTP server ($pptp_ext).  Here are the relevant pf.conf 
entries I have:

binat   on $ext_if                                      \
         from $pptp_nat to any -> $pptp_ext

pass    in quick on $ext_if inet proto tcp                      \
         from any                                                \
         to $pptp_nat port pptp modulate state
pass    in quick on $ext_if inet proto gre      \
         from any                                \
         to $pptp_nat keep state

pass    out log quick on $ext_if inet proto gre \
         from $pptp_ext				\
         to any keep state

Short of switching the PPTP server off NAT (not something I want to have 
to do), I'm not sure what step I'm missing.

Well, then there's always that I've spent too much time on this and 
should step back from it for a bit to get a clearer head.  In any case, 
any additional help on this would be greatly appreciated.

Keith

Michael Erdely wrote:

> I did not modify net.inet.gre.allow.
> I did not remove the gre pseudo-device.
> 
> It was actually this simple:
> #  cd /usr/src
> #  tar -xzf ~/src.tar.gz
> #  tar -xzf ~/sys.tar.gz
> #  cd /usr
> #  patch -p0 < ~/pf.c-patch
> #  cd /usr/src/sys/arch/i386/conf
> #  config GENERIC
> #  cd ../compile/GENERIC
> #  make depend; make
> #  cp /bsd /bsd.old
> #  cp bsd /bsd
> #  reboot
> 
> # Success.
> ksh: Success.: not found
> 
> -ME
> 
> 
> -----Original Message-----
> From: Keith McDuffee [mailto:gudlyf@realistek.com] 
> Sent: Saturday, May 31, 2003 1:22 AM
> To: Michael Erdely
> Cc: misc@openbsd.org
> Subject: Re: OpenBSD 3.3 and MS PPTP
> 
> 
> Hm, I have the same binat setup that you're talking about, but still I'm 
> getting the same results.
> 
> Am I correct that you no longer have to compile the kernel without the 
> gre pesudo-device?  Should the sysctl new.inet.gre.allow be set to 1? 
> I've tried the kernel both ways and the sysctl as well, but I want to be 
> sure I have things set correctly in that respect first before I proceed.
> 
> Thanks again.
> 
> Michael Erdely wrote:
> 
> 
>>Keith,
>>
>>In my case, I'm binat'ing an ip alias on the outside interface to the pptp
>>server.
>>
>>But, just for you, as a test, I commented out the binat and put these in:
>>rdr on $pub_if inet proto gre from any to $pub_ip2 -> $pptp
>>rdr on $pub_if inet proto tcp from any to $pub_ip2 port 1723 -> $pptp \
>>
>>        port 1723
>>
>>-ME
>>
>>-----Original Message-----
>>From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of
>>Keith McDuffee
>>Sent: Saturday, May 31, 2003 12:54 AM
>>To: misc@openbsd.org
>>Subject: Re: OpenBSD 3.3 and MS PPTP
>>
>>
>>Sorry I missed the list on this.  I'll try to keep it here now...
>>
>>I see your filter rules below, but what about the nat rules?  Just the 
>>binat to/from $pptp, or did you need a rdr as well?
>>
>>I do now see that the binat seems to be working the way it should, with 
>>the middle address being the correct address when looking at the state 
>>table.
>>
>>Thanks again,
>>
>>Keith