Hi "oneforall" I do not understand your problem with Source and Destination NAT 100%? This is realy quite simple, just enter NAT in google and you will get perfect detailed information about DNAT ans SNAT. This is nothing developed by Endian. "DNAT is a technique for transparently changing the destination IP address of an en-route packet and performing the inverse function for any replies." And "A common definition for Source NAT is the counterpart of Destination NAT (DNAT)." So in Destination NAT the DESTINATION IP is changed and in Source NAT the SOURCE IP is changed!!?? So the explanation is already part of the name =)) I think for what to use DNAT is clear, right? Publishing a single Service or server to the www is one possible usage... For SNAT (or better let's talk from SourceNAT 'cause SNAT can have other meanings aswell) one possible scenario could be that you would like a webserver in Zone orange to send it's packets over external IP1 while the pcs in green zone use external IP2. In this case efw would have to translate all ips coming from network orange and green. In efw this would look like this: Source: NetworkIP from your orange Zone which you would like to be transformed Target: Uplink main (red) Service/Port: ALL (or just the services/ports you need) NAT: NAT (--> telling efw that it must translate the packets) Sourceadress: Uplink main - IP: IP1 Source: NetworkIP from your green Zone which you would like to be transformed Target: Uplink main (red) Service/Port: ALL (or just the services/ports you need) NAT: NAT (--> telling efw that it must translate the packets) Sourceadress: Uplink main - IP: IP2 >From outside your network it will look like as your webserver is responding from IP1 and all your PCs from IP2 =) That's not damn hard to understand, right? As it sounds for me you can ignore Incoming routed traffic: you won't need it! Give yourself a overview looking at: http://en.wikipedia.org/wiki/Network_address_translation cu ________________________________
Von: oneforall immortal [mailto:oneforal...@hotmail.com] Gesendet: Donnerstag, 31. Dezember 2009 12:28 An: efw-user@lists.sourceforge.net Betreff: Re: [Efw-user] firewall rules are hard to use the target should be where the router box is going to send it too. Thats always been the way I thought of and most people But now I'm completely lost on why taget has become a totally new meaning , that isn't the first thought of at all. The source is easy to understand its where it came from the lan the net you own pc. then the router/firewall sends it to the target. plain and simple and not chamged to something that isn't even close to the meaning of the words. I wish too there was some standard examples and it might clear it up buit the defination just send most for a loop. 1) source(incoming to web page) firewall box 192.168.1.1 target lan(green)192.168.1.2:81(apache server) was confused on Destination NAT <https://192.168.1.1:10443/cgi-bin/dnat.cgi> and incoming routed traffic(this still sounds like it could be for the incoming traffic for a web page on port 81) but it just didn't look like it would work and destination nat did. So as it stands I have no idea what incoming routed traffic is good for . Plus I still have no idea how to alow the same box to use the browser and put in the domain name with out it timing out and only working wiht localhost:81. 2.2 I never had this problem at all 2) I see no way to be able to add the web pages I want to bypass the proxy but again its either gone or to darn complicated for something that WAS simple to do. 3) outgoing traffic I'm glad is still only one tab and not split making it even more confusing . like Destination NAT, Source NAT and Incoming routed traffic(see that swhy this sound like it should be for routing to you servers) or just any other pc on the lan . Source NAT I've given up by now again trying to figure out what its for because nothing is as it sounds any more. Even looking again it looks like 3 ways to do the same darn thing but instead of just source/target(destination) port , its access.target(what this is now I've given up trying to comprehend the non common definition). anyway I give up > From: pmsolive...@gmail.com > To: efw-user@lists.sourceforge.net > Date: Wed, 30 Dec 2009 19:25:28 +0000 > Subject: Re: [Efw-user] firewall rules are hard to use > > 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. > > On Wednesday 30 December 2009 10:27:30 jonas kellens wrote: > > Pedro, > > > > This is the right configuration for port forwarding to a LAN-client : > > > > Access from : any > > Target : <any Uplink> > > Port :TCP 51413 > > Translate to IP 192.168.1.25 port 51413 > > > > > > "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 ?! > > > > Even with a good understanding of IPtables, I don't get this 'acces', > > 'target' and 'source'. > > > > Can you maybe post a link to some examples cause I feel that the > > documentation of Endian lacks some explanatory examples. > > > > > > Jonas. > > > > > > On Wed, 2009-12-30 at 10:12 +0000, Pedro M. S. Oliveira wrote: > > > > > Hi > > > I disagree on you both about the new EFW firewall interface, I see it > > > much more complete and feature rich than the previous one. This new > > > interface has more advanced options that you may use and it reseable > > > best the iptables capabilities. In my opinion this is the way to go > > > and it will be the difference between an home router and a business > > > system. > > > im sure that with a bit of reading about firewall and the way they > > > work you ll get there. > > > cheers, > > > pedro > > > > > > > > -- > ------------------------------------------------------------------------ ---------------------------------- > Pedro M. S. Oliveira > IT Consultant > Email: pmsolive...@gmail.com > 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-user@lists.sourceforge.net > 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=9691810>
------------------------------------------------------------------------------ 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-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/efw-user
