From: oneforall i. <one...@ho...> - 2009-12-31 22:34:26
|
Thanks for the help but can we keep it simple and less rech. > From: pms...@gm... > To: efw...@li... > Date: Thu, 31 Dec 2009 15:04:45 +0000 > Subject: Re: [Efw-user] firewall rules are hard to use > > Hi, > Imagine the following network schema > > EFW 123.12.32.1 - Red interface > Router 192.168.2.253 - GW to network 10.2.3.0/24 > EFW 192.168.2.254 - Green interface netmask 255.255.255.0 > PC clients 192.168.2.1-50 lets use the basics the network card(nic) for eth0(red) and the eth1 for the lan(green).Althou for many years the default for a simple rc.firewall ans still is green was default eth0. But efw lan nic with 192.168.1.1(or 10.0.0.0 is the other chioce of lan ips) but lets stick to 1 and not a mix please. the EFW 123.12.32.1 - Red interface ,I'm assuming you mean the isp assigned ip here Router 192.168.2.253 - GW to network 10.2.3.0/24 no idea if this is you mean efw as a router or another router box(pc or store bought) on the lan EFW 192.168.2.254 - Green interface netmask 255.255.255.0 , I'm assuming you mean the lan nic PC clients 192.168.2.1-50 this is easy instead of all using 192.168.1.x it 192.168.2.x . I'm assuming your trying to discribe it hear that the lan(ps's) are on 192.168. and the servers using the 10.0.0.x ip's . > > Client machines on network 192.168.2.0/24 with only one default gw (and no specif routes) that will be endian green ip 192.168.2.254. > > If you want your clients to get the network 10.2.3.0/24, lets imagine you have 10.2.3.1 as web server the package will flow like this: > > Outgoing path: > PC (192.168.3.32) -> EFW GREEN -> GW (192.168.2.243) -> WEB SERVER (10.2.3.1) here I'm guessing you mean it to be 192.168.2.32 not 192.168.3.32 > Incoming path: is this the incoming to the webserver ? because as you follow the ->(path) its showiong it as outgoing from the server to the PC on the lan(lan not remote/web since its a local ip#) think of it this way like the bank note book. The debt is theirs not yours , you have toi think on what it means to them. So is incoming to the server here or is it the client(lan/remote(web). That why I liked port forwarding better it was all making me think of incoming(from the web/lan) to the efw(firewall router), and being forwarded to the ip# of the lan or just going to red(which is easy to figure out where it was going then) and outgoing tab was exactly that . outgoing from the lan/server boxes and efw > WEB SERVER (10.2.3.1) -> GW (192.168.2.243) -> PC (192.168.2.32) > as you see the returning path is different, this is due to ARP resolution on switches that found out that the destination IP is on it's local network, the problem is that the some equipment (not all), and most of the PCs firewalls wont accept this packet as they were especting the packet to arrive from the endian green interface. > That said you may use source nat, this will make that all packets originating from endian have endian as source address and it will allow you to maintain the correct return path. > WEB SERVER (10.2.3.1) -> GW (192.168.2.243) -> EFW GREEN -> PC ok so then when I was trying to get my lan box(192.168.1.10, web server box not headless, but gui browsers etc too). I tried thinking that for it to work with the domain name it was needed to add port 81 here. But I guess I just wasn't hitting the right combo then. I'm trying it now and see if I can get it this time whats weird too is the other lan boxes are able to put in the domain name , just not the same box the server is one . ok Destination green and interface 2 (zone: green) whats the diff with those? other than thje way its writen they still are both green so are they even diffrent? NAT get to here and its such a confusing. we start with Source so it makes no sence nat to source . why is it trying to reverse here well I tried again and still no luck . err this is way to darn frustrating. > > About routed traficc the situation is the oposite you woun't need NAT but you want the scr and dst headers on the packet to be maintained, the incovinience is that all the routers should know the path to all networks in question to work as no forwarding is done, in reallity i like it more as there aren't portforwarding rules in every FW. > > > > On Thursday 31 December 2009 10:23:39 oneforall immortal wrote: > > > > Destination NAT, Source NAT, Incoming routed traffic > > these to are split up and make no sence to me now. > > > > > > > > > > From: jon...@te... > > To: efw...@li... > > Date: Wed, 30 Dec 2009 21:32:45 +0100 > > Subject: Re: [Efw-user] firewall rules are hard to use > > > > > > > > > > > > > > > > > > > > > > Thank you Pedro for your explanation. I much appreciate it !! > > > > > > > > Things become clearer... > > > > > > > > > > > > On Wed, 2009-12-30 at 19:25 +0000, Pedro M. S. Oliveira wrote: > > > > Hi Jonas, > > When you specify target green or 192.168.1.25 this means that the packet arriving on the uplink should have a destination ip of the green network or 192.168.1.25 and usuually that doesn't happen because they are marked to arrive at your red ip address (usually a public ip from your provider if you use a classic network schema). > > > > lets put it this way: > > > > > > 183.23.13.24 - ExtHost - host on internet > > 213.21.23.23 - RedIP - your red ip address > > 192.168.1.254 - GreenIP - your green ip address > > 192.168.1.25 - HTSrv - your http server > > > > Now lets see the situation you described: > > > "Access from : RED" does not work. I don't understand why. Do you ? > > > "Target : GREEN" or "Target : 192.168.1.25" does not work. I don't > > > understand why I can't use my LAN-client as target, as this is the > > > client to where to portforward ?! > > > > ExtHost -> RedIP -> GreenIP - forwarding refused because your rule says forward all packages with destination 192.168.1.25 but the package has destination 213.21.23.23 (RedIP) and that's why it's not forwarded > > > > To accomplish this you could have something like: > > Access from: Any (or anyuplink or uplink) > > Target: Uplink or any uplink > > IP: your internal server ip (192.168.1.25) > > Type: IP > > DNAT: NAT > > Service: HTTP > > > > This way: > > ExtHost -> RedIP -> GreenIP - forwarding accepted because access from and target are matched as well the service port and packet will be forwarded to the HTServ > > > > Access from is related to where the package is coming from. > > Target is the package destination on ip header not your local intended destination. > > > > With this new features on EFW you can have a greater control on more complex networks where you may have different layers of firewalling and this will be done just relying on the web interface, on version 2.2 with more complex rules and different layers of firewalling you needed to write a bunch of rules manually on command line. > > > > > > > > > > > > _________________________________________________________________ > > Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. > > http://go.microsoft.com/?linkid=9691817 > > -- > ---------------------------------------------------------------------------------------------------------- > Pedro M. S. Oliveira > IT Consultant > Email: pms...@gm... > URL: http://www.linux-geex.com > Cellular: +351 96 5867227 > ---------------------------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Efw-user mailing list > Efw...@li... > https://lists.sourceforge.net/lists/listinfo/efw-user _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://go.microsoft.com/?linkid=9691815 |