[ Charset ISO-8859-1 unsupported, converting... ]
> Darren Reed wrote:
> 
> > The patch below will stop the panics but I really should try and fix
> > the underlying problem too, tqe_ifq should never be NULL...
> 
> Thanks a lot. You were correct - the panic no longer happens. You were,
> of course, also correct in that the actual problem is somewhere else. In
> my situation the PPTP proxy still doesn't work for incoming connections,
> since some packets seem to "bypass" the proxy.
> 
> 15:15:10.237084 dc0 @0:11 p 194.126.106.110,1034
>   -> 127.0.0.1,1723 PR tcp len 20 48 -S K-S IN NAT
> 15:15:10.256907 dc0 @0:8 b 127.0.0.1
>   -> 194.126.106.110 PR gre len 20 (74) OUT

Hmm, let me see here:

rdr dc0 194.126.106.106/32 port 1723 -> 127.0.0.1 port 1723 proxy pptp

pass in log first quick on dc0 proto tcp  \
        from any to 127.0.0.1/32 port = 1723 \
        flags S keep state

You're using the proxy in a way I doubt it has been written to work with :)

If you do an "ipnat -l" and "ipfstat -sl", can you see NAT/state entries
that should match the 2nd packet above that gets blocked ?

Also, try it with the patch below.

Cheers,
Darren

Index: ip_pptp_pxy.c
===================================================================
RCS file: /devel/CVS/IP-Filter/ip_pptp_pxy.c,v
retrieving revision 2.10.2.6
diff -u -r2.10.2.6 ip_pptp_pxy.c
--- ip_pptp_pxy.c       25 Nov 2004 15:37:37 -0000      2.10.2.6
+++ ip_pptp_pxy.c       1 Feb 2005 03:04:00 -0000
@@ -118,7 +118,7 @@
        fi.fin_flx &= ~FI_TCPUDP;
        fi.fin_flx |= FI_IGNORE;
 
-       nat2 = nat_new(&fi, ipn, &pptp->pptp_nat, NAT_SLAVE, NAT_OUTBOUND);
+       nat2 = nat_new(&fi, ipn, &pptp->pptp_nat, NAT_SLAVE, nat->nat_dir);
        pptp->pptp_nat = nat2;
        if (nat2 != NULL) {
                (void) nat_proto(&fi, nat2, 0);

Reply via email to