I've been trying to set up a LEAF/Bering firewall at home to allow a connection to my employer's VPN (PPTP). Here is a rough picture of my connection:
Win98 client ---> Bering ---> Router ---> ISP ---> Internet ---> Company My internal network (Win98 -> Bering) uses a private IP space (192.168.1.0/24). I'm connected to my ISP via a DSL connection in bridge mode, so my router also has a private IP (192.168.x.y, x != 1). The ISP then does NAT on that, so my packets are NAT'ed twice, once at the Bering firewall and again by my ISP. I've got a fairly straightforward Shorewall configuration on the Bering box, defining just two zones (net and loc). Outgoing traffic from loc to net is allowed, related traffic is allowed back in. RFC1918 addresses are not allowed to flow from net -> loc, except for those on my bridge connection (192.168.x.y) to the ISP. What I see happening is that packets coming back from the company are getting rejected by the "norfc1918" rule, as shown by the trace below (just two messages are shown, I get a bunch more but they are all pretty much the same): Nov 9 02:29:15 firewall kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT=eth0 SRC=192.168.p.q DST=192.168.1.1 LEN=56 TOS=0x00 PREC=0x00 TTL=253 ID=20062 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.x.y DST=a.b.c.d LEN=50 TOS=0x00 PREC=0x00 TTL=125 ID=28417 PROTO=47 ] Nov 9 02:29:18 firewall kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT=eth0 SRC=192.168.p.q DST=192.168.1.1 LEN=56 TOS=0x00 PREC=0x00 TTL=253 ID=20068 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.x.y DST=a.b.c.d LEN=50 TOS=0x00 PREC=0x00 TTL=125 ID=28929 PROTO=47 ] In these traces, "a.b.c.d" is the IP for my company's PPTP server, "192.168.1.1" is the (internal) IP for my Win98 client, "192.168.x.y" is the IP of my firewall (ISP side), and "192.168.p.q" is (I think; p != x != 1) the private IP being used inside my company's LAN (i.e., on the other side of the PPTP server). I'm not sure how to read the log message, but it appears to me that the part in the brackets is either an indicator of the GRE wrapper for the packet or the original packet that is "related" to the incoming packet. In any case, it appears that the filtering rules are keying on the private IP from inside my company and rejecting the packet. What I don't understand is why the packet isn't marked as coming from the PPTP server. I should note that I have the ip_conntrack_pptp and ip_nat_pptp modules loaded. Also, I've been told that I can't do this successfully due to the fact that my "external" (i.e., the router) address is a private, non-routable IP and that I have to get (and pay for) a "real" static IP in order to get this to work. What I want to know, though, is why. If it were really the case that my non-routable IP were the problem, I would have expected the packets to never even reach me. Any light that can be shed on this situation would be greatly appreciated. If I really need to buy an external IP, I will, but right now I'm not convinced that even that would work. Thanks. -- David A. Bright [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
