[ 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);