I've got a VPN server setup, and after HOURS of debugging the stupid setup, I've finally reached a stopping point: SuSEfirewall2 doesn't work like it used to. I used to be able to say something like this: FW_DEV_INT="eth0 ppp0" And it would wrap the VPN connections into the LAN, and I'd be done. Now I'm saying: FW_DEV_INT="eth-id-00:a0:c9:2a:4b:03 ppp0" But I'm getting this sort of error message: Jan 8 22:54:39 server1 kernel: SFW2-FWDint-DROP-DEFLT IN=ppp0 OUT=eth1 SRC=172.16.0.200 DST=172.16.0.1 LEN=96 TOS=0x00 PREC=0x00 TTL=127 ID=14905 PROTO=UDP SPT=137 DPT=137 LEN=76 Why is the firewall blocking packets between 2 internal interfaces? Regards, dk P.S. One of the things I struggled the longest with was the fact that the /etc/ppp/ip-up script calls SuSEfirewall2 *immediately* after handing out an IP address. This confuses pptpd, which needs to wait a few seconds. It appears that there aren't any options for making it do this. (I tried "stimeout 30" in /etc/pptpd.conf, but that didn't work. That parameter isn't in the man page, so maybe Google showed me an older option. Whatever.) The only thing that would work was to comment out the place where SuSEfirewall2 is invoked in /etc/ppp/ip-up, wait a few extra seconds, *then* run SuSEfirewall2. I can put a "sleep 15" or something in that function, but now I'm finding that it continues to block the packets as above.
Replying to myself: On Sat, 2005-01-08 at 23:00 -0500, David Krider wrote:
Why is the firewall blocking packets between 2 internal interfaces?
Option 23 in /etc/sysconfig/SuSEfirewall fixes this: FW_ALLOW_CLASS_ROUTING="yes"
P.S. One of the things I struggled the longest with was the fact that the /etc/ppp/ip-up script calls SuSEfirewall2 *immediately* after handing out an IP address. This confuses pptpd, which needs to wait a few seconds. It appears that there aren't any options for making it do this. <SNIP> The only thing that would work was to comment out the place where SuSEfirewall2 is invoked in /etc/ppp/ip-up, wait a few extra seconds, *then* run SuSEfirewall2. I can put a "sleep 15" or something in that function <SNIP>
I still haven't got a good answer for this. I guess it's just my old PPro 200 working as my firewall. Maybe I should give it up and let my (nice) file server also serve as my firewall. It takes long enough to get through a run of SuSEfirewall2 that it can cause pptpd to lose track of its control packets such that it will drop the connection. There are several that need to be transferred right after the connection is intiated, so the sleep thing might still work to avoid that, but randomly waiting for some period of time also causes problems, because I might hit a time when the control side of the VPN needs to exchange some more packets. It's sort of a race condition. Anyone responsible for the firewall script watching this list? dk
participants (1)
-
David Krider