|
||||||||||
Guys, I'm just starting to research the rule output so I can better read this... can any of you tell me if you see anything out of place that would cause a PPTP session to fail from a client on the LAN side to a server on the WAN side, with no NATing enabled? I did change some IP's to fall in line with my previous network description. Here is the output of ipfstat -hnio: $ ipfstat -hnio 0 @1 pass out quick on lo0 from any to any 234 @2 pass out quick on xl0 proto udp from 10.0.3.1/32 port = 67 to any port = 68 0 @3 pass out quick on xl0 from 10.0.3.0/24 to 216.xxx.xxx.0/32 0 @4 pass out quick on xl0 from 216.253.204.0/32 to 10.0.3.0/24 0 @5 pass out quick on xl1 proto udp from any port = 68 to any port = 67 183 @6 pass out quick on xl0 from any to any keep state 1036 @7 pass out quick on xl1 from any to any keep state 0 @8 block out log quick from any to any 0 @1 pass in quick on lo0 from any to any 0 @2 block in log quick from any to any with short 0 @3 block in log quick from any to any with ipopt 118 @4 pass in quick on xl0 proto udp from any port = 68 to 255.255.255.255/32 port = 67 199 @5 pass in quick on xl0 proto udp from any port = 68 to 10.0.3.1/32 port = 67 0 @6 pass in quick on xl0 from 10.0.3.0/24 to 216.xxx.xxx.0/32 0 @7 pass in quick on xl0 from 216.xxx.xxx.0/32 to 10.0.3.0/24 0 @8 block in log quick on xl1 from 10.0.3.0/24 to any 0 @9 block in log quick on xl1 proto udp from any port = 67 to 10.0.3.0/24 port = 68 0 @10 pass in quick on xl1 proto udp from any port = 67 to any port = 68 0 @11 skip 2 in on xl0 from 216.xxx.xxx.0/32 to any 14884 @12 skip 1 in on xl0 from 10.0.3.0/24 to any 31 @13 block in log quick on xl0 from any to any 13207 @14 skip 1 in proto tcp from any to any flags S/FSRA 1416 @15 block in log quick proto tcp from any to any 14877 @16 block in log quick on xl0 from any to any head 100 1707 @1 pass in quick from 10.0.3.0/24 to 10.0.3.1/32 keep state group 100 13170 @2 pass in quick from any to any keep state keep frags group 100 4700 @17 block in log quick on xl1 from any to any head 200 4700 @1 pass in quick from any to any keep state keep frags group 200 0 @18 block in log quick from any to any Thanks, --David -----Original Message----- From: Fred Wright [mailto:fw at well dot com] Sent: Friday, August 13, 2004 4:03 PM To: m0n0wall at lists dot m0n0 dot ch Subject: RE: [m0n0wall] PPTP through m0n0 not authenticating On Fri, 13 Aug 2004, Herron, David S wrote: > I appreciate hearing that what I've done is correct. I DO have the > 'Enable advanced outbound NAT' turned on, and the table is empty. That > was the only combination that did what I wanted - No NATing at all from > the m0n0wall. You are correct in assuming that all NAT is done from our > primary firewall. > > However, my problem still lingers - even with no NATing, the connection > will not authenticate. Hmmmph! Hmm... I presume you also have the routing entry I mentioned, since otherwise you wouldn't get the return packets from the control connection. Make sure m0n0wall's PPTP feature is turned off, since otherwise it will divert the GRE packets. I don't think explicitly allowing inbound GRE through m0n0wall should be needed, since the first GRE packet should be outbound and create a state entry, but it's worth a try if the above doesn't fix it. If all else fails, you could look at packet traces. :-) Fred Wright --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch |