Thanks for the help but can we keep it simple and less rech.
> From: pmsolive...@gmail.com
> To: efw-user@lists.sourceforge.net
> 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: jonas.kell...@telenet.be
> > To: efw-user@lists.sourceforge.net
> > 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: 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=9691815------------------------------------------------------------------------------
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
