Hello, I am faced with an unsual requirement that I havn''t been able to
figure out how to accomplish.
Currently I am using Bearing LEAF Firewall 1.0 RC3 which incorporates
shorewall as the filtering mechanism.
I need to install a Netscreen 5XT VPN box so that I can connect to my
companies internal network without usin the Software VPN solution I
currently have. I have 1 ISP connection over 1.1 SDSL
I have three interfaces in my firewall but am only using 2 currently.
I will try to diagram out what I would like to do.
________
+------------+ /
| | |
+-------------+ DSL Router +-------
__ | | | /
___/ \_ +------+---------+ +-----+------+ |
_/ \__ | if1 | | /
/ \ | | | |
| Local network -----+if3 Shorewall | | | Internet
\_ __/ | | | |
\__ __/ | if2 | | \
\___/ +------+---------+ +-----+------+ |
| | | \
+-------------+ Netscreen + \_________
| |
+------------+
Local Network - 192.168.1.0/24
Public network from DSL provider - 66.92.211.96/28
Netscreen Private addresses - 139.99.238.0/29 (This currently has a DHCP
server active for 4 addresses. I will turn it off)
Currently I am using both SNAT and DNAT from my local network to the
Internet.
Can anyone help me configure this?
Lew Newby
On Monday 26 January 2004 02:27 pm, Lew Newby Jr wrote:> > Currently I am using both SNAT and DNAT from my local network to the > Internet. > > Can anyone help me configure this? >We are going to need some more specifics if you want our help. a) What part of the configuration don''t you understand? b) How is the shorewall box going to decide which traffic to route through the Netscreen? c) What are the firewalling requirements for this setup? We''re willing to help but you can''t just give us a diagram and ask us to configure your system for you... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hrmmm ok I''ll see if I can explain what I am thinking of here. I understand the theory of what I am trying to do. I don''t understand where to start within Shorewall to accomplish this. I need the Shorewall box to be both a router and a Firewall. It must route packets destined from the 139.99 subnets AND for a big Class B 158.140 subnet through the netscreen using a static route. It must masquerade the internal 192.168.0 address into the 139.99 addresses as it passes through the third interface on to the netscreen All traffic from the 158.140 and 139.99 subnets must be allowed through in both directions while not allowing most traffic through the main Internet interface. Can a shorewall system act as a router as well as a firewall? Lastly is this even possible using a Bearing LEAF distribution OR would I be better off putting a full blown distribution on the system and using that? Lew Tom Eastep wrote:>On Monday 26 January 2004 02:27 pm, Lew Newby Jr wrote: > > > >>Currently I am using both SNAT and DNAT from my local network to the >>Internet. >> >>Can anyone help me configure this? >> >> >> > >We are going to need some more specifics if you want our help. > >a) What part of the configuration don''t you understand? >b) How is the shorewall box going to decide which traffic to route through the >Netscreen? >c) What are the firewalling requirements for this setup? > >We''re willing to help but you can''t just give us a diagram and ask us to >configure your system for you... > >-Tom > >
On Mon, 26 Jan 2004, Lew Newby Jr wrote:> I understand the theory of what I am trying to do. I don''t understand > where to start within Shorewall to accomplish this. I need the Shorewall > box to be both a router and a Firewall. >Shorewall has almost *NOTHING* to do with routing. With Shorewall 2.0, Shorewall will be completely out of the picture.> It must route packets destined from the 139.99 subnets AND for a big > Class B 158.140 subnet through the netscreen using a static route.That part has nothing to do with Shorewall -- try the LEAF list. This basically involves adding "up" clauses to the interface to the netscreen in /etc/network/interfaces (I think -- I don''t run Bering but that''s the way that it is done in Debian and Bering''s network management is Debian-based).> It must masquerade the internal 192.168.0 address into the 139.99 > addresses as it passes through the third interface on to the netscreenIn /etc/shorewall/masq, add this entry: <IF to netscreen> <local if> Example: If the local interface is eth1 and the netscreen interface is eth2 then: eth2 eth1 That assumes that the netscreen and downstream hosts know how to route traffic to eth1 on the firewall.> All traffic from the 158.140 and 139.99 subnets must be allowed through > in both directions while not allowing most traffic through the main > Internet interface.The netsceen interface should be associated with it''s own zone. then simply use normal Shorewall policies/rules to control allowed traffic.> > Can a shorewall system act as a router as well as a firewall? >All shorewall systems with more than one interface are routers!!!!!!!!!!!> Lastly is this even possible using a Bearing LEAF distribution OR would > I be better off putting a full blown distribution on the system and > using that? >Bering is fine. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Mon, 26 Jan 2004, Tom Eastep wrote: I should have proofread this before posting (so what''s new?)...> On Mon, 26 Jan 2004, Lew Newby Jr wrote: > > > I understand the theory of what I am trying to do. I don''t understand > > where to start within Shorewall to accomplish this. I need the Shorewall > > box to be both a router and a Firewall. > > > > Shorewall has almost *NOTHING* to do with routing. With Shorewall 2.0, > Shorewall will be completely out of the picture.That is to say that Shorewall doesn''t touch routing in 2.0.> > > It must route packets destined from the 139.99 subnets AND for a big > > Class B 158.140 subnet through the netscreen using a static route. > > That part has nothing to do with Shorewall -- try the LEAF list. This > basically involves adding "up" clauses to the interface to the netscreen > in /etc/network/interfaces (I think -- I don''t run Bering but that''s the > way that it is done in Debian and Bering''s network management is > Debian-based).Translation: In Debian, the /etc/network/interfaces file describes the network interfaces on the system. Within the description of an interface, you can include "up" followed by a command that you want executed when the interface is brought up. That is the way that static routes are configured. For example, here''s an excerpt from my own /etc/network/interfaces: auto eth1 iface eth1 inet static address 192.168.2.1 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 up ip route add 206.124.146.177 dev eth1 The last line above adds a host route to host 206.124.146.177 from eth1 when that interface is brought up.> > > It must masquerade the internal 192.168.0 address into the 139.99 > > addresses as it passes through the third interface on to the netscreen > > In /etc/shorewall/masq, add this entry: > > <IF to netscreen> <local if> > > Example: > > If the local interface is eth1 and the netscreen interface is eth2 then: > > eth2 eth1 > > That assumes that the netscreen and downstream hosts know how to route > traffic to eth1 on the firewall. >In other words, if you assign that interface an IP address in the 139.99.0.0/16 network. Hope this helps, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Thanks Tom,
The answers are marginally helpful. I''ll go off and figure it
out. It is a shame that such a nice tool is represented with the
attitude supplied in this thread and some of the docs I have read. I was
hoping for more of a community than an ego, shame on me.
Lew
Tom Eastep wrote:
>On Mon, 26 Jan 2004, Tom Eastep wrote:
>
>I should have proofread this before posting (so what''s new?)...
>
>
>
>>On Mon, 26 Jan 2004, Lew Newby Jr wrote:
>>
>>
>>
>>>I understand the theory of what I am trying to do. I don''t
understand
>>>where to start within Shorewall to accomplish this. I need the
Shorewall
>>>box to be both a router and a Firewall.
>>>
>>>
>>>
>>Shorewall has almost *NOTHING* to do with routing. With Shorewall 2.0,
>>Shorewall will be completely out of the picture.
>>
>>
>
>That is to say that Shorewall doesn''t touch routing in 2.0.
>
>
>
>>>It must route packets destined from the 139.99 subnets AND for a big
>>>Class B 158.140 subnet through the netscreen using a static route.
>>>
>>>
>>That part has nothing to do with Shorewall -- try the LEAF list. This
>>basically involves adding "up" clauses to the interface to the
netscreen
>>in /etc/network/interfaces (I think -- I don''t run Bering but
that''s the
>>way that it is done in Debian and Bering''s network management
is
>>Debian-based).
>>
>>
>
>Translation: In Debian, the /etc/network/interfaces file describes the
>network interfaces on the system. Within the description of an interface,
>you can include "up" followed by a command that you want executed
when the
>interface is brought up. That is the way that static routes are
>configured. For example, here''s an excerpt from my own
>/etc/network/interfaces:
>
>auto eth1
>iface eth1 inet static
> address 192.168.2.1
> netmask 255.255.255.0
> network 192.168.2.0
> broadcast 192.168.2.255
> up ip route add 206.124.146.177 dev eth1
>
>
>The last line above adds a host route to host 206.124.146.177 from eth1
>when that interface is brought up.
>
>
>
>>>It must masquerade the internal 192.168.0 address into the 139.99
>>>addresses as it passes through the third interface on to the
netscreen
>>>
>>>
>>In /etc/shorewall/masq, add this entry:
>>
>><IF to netscreen> <local if>
>>
>>Example:
>>
>>If the local interface is eth1 and the netscreen interface is eth2 then:
>>
>>eth2 eth1
>>
>>That assumes that the netscreen and downstream hosts know how to route
>>traffic to eth1 on the firewall.
>>
>>
>>
>
>In other words, if you assign that interface an IP address in the
>139.99.0.0/16 network.
>
>Hope this helps,
>-Tom
>--
>Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
>Shoreline, \ http://shorewall.net
>Washington USA \ teastep@shorewall.net
>
>
On Monday 26 January 2004 07:38 pm, Lew Newby Jr wrote:> Thanks Tom, > The answers are marginally helpful. I''ll go off and figure it > out. It is a shame that such a nice tool is represented with the > attitude supplied in this thread and some of the docs I have read. I was > hoping for more of a community than an ego, shame on me. >I''m sorry that my support doesn''t meet your expectation. Hopefully some Shorewall user on the list will be willing to configure your firewall/router for you. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Monday 26 January 2004 08:08 pm, Tom Eastep wrote:> On Monday 26 January 2004 07:38 pm, Lew Newby Jr wrote: > > Thanks Tom, > > The answers are marginally helpful. I''ll go off and figure it > > out. It is a shame that such a nice tool is represented with the > > attitude supplied in this thread and some of the docs I have read > > I was hoping for more of a community than an ego, shame on me. > > I''m sorry that my support doesn''t meet your expectation. Hopefully some > Shorewall user on the list will be willing to configure your > firewall/router for you.And you might find more sympathetic ears on the Shorewall-newbies list -- when you post on the list for experienced users, you get me, like it or not. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hi guys Been a while i posted but ...you guessed it everything works like a charm. I have noticed as of late that Tom has mentionned that routing support will be taken out and that from what i have gather no rpm''s will be released? with future releases or am i mistaken. If there is somewhere i can get some information regarding these questions it would be much appreciated.... And as others have mentionned Tom great work on a great project and as per the reply to the other user regarding split access, if the occasional reading a man page or FAQ is an issue then you will have difficulty running any piece of software. I work for a support department and i have noticed the following free support tends to get people to feel they need to express themselves alot... Assumption incorrect. Call IBM or Microsoft and complain guess what the call starts like this "May i have your credit card please." So be courteous and support will be on its way. So there is no misunderstanding these comments are not directed towards Tom and im not looking to start any arguement but sometimes i personnaly get bother how people have no respect... Tom all i can say is gone are the days when i created my own firewall and did troubleshooting for a week to get forwarding working.. Thank you Nick Sklav
On Monday 26 January 2004 08:01 pm, Nick Sklavenitis wrote:> I have noticed as of late that Tom has mentionned that routing support > will be taken out and that from what i have gather no rpm''s will be > released? with future releases or am i mistaken.No thats not quite what I heard him say... he said shorewall won''t touch the routing. As for the RPMs, its one of those packages that goes in just as easily with tarballs as anything else. -- John Andersen - NORCOM http://www.norcomsoftware.com/
On Tue, 2004-01-27 at 00:39, John Andersen wrote:> On Monday 26 January 2004 08:01 pm, Nick Sklavenitis wrote: > > I have noticed as of late that Tom has mentionned that routing support > > will be taken out and that from what i have gather no rpm''s will be > > released? with future releases or am i mistaken. > > No thats not quite what I heard him say... > he said shorewall won''t touch the routing. > As for the RPMs, its one of those packages that goes in > just as easily with tarballs as anything else.Would still be nice to have the rpms for maintenance reasons and for the fact that i have grown accustomed to the way shorewall works. Also im currently using fedora and and i would like to be able too install shorewall and have the package manager work as well with it. Then again i might have totally misunderstood and if that is the case my apologies in advance.
On Monday 26 January 2004 08:48 pm, Nick Sklavenitis wrote:> Would still be nice to have the rpms for maintenance reasons and for the > fact that i have grown accustomed to the way shorewall works. > > Also im currently using fedora and and i would like to be able too > install shorewall and have the package manager work as well with it. > > Then again i might have totally misunderstood and if that is the case my > apologies in advance.I understand, its nice to have it in the rpm database as upgrades are easier. I''ve avoided it because the RPMs always conflicted with the SuSE smp kernel package, (suprious) and so I always installed with tars on my SuSE machines (many of which are dual CPU). Its not a package I update often (IINBDFI) as my needs are modest and stable. -- John Andersen - NORCOM http://www.norcomsoftware.com/
Just to verify, assuming my proxy ARP is on zone wan, is the following general rule format correct? ACCEPT wan lan:68.109.228.3 tcp http -
On Monday 26 January 2004 11:30 pm, Gavin Thomas Nicol wrote:> Just to verify, assuming my proxy ARP is on zone wan, is the following > general rule format correct? > > ACCEPT wan lan:68.109.228.3 tcp http - >Yes. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Monday 26 January 2004 09:01 pm, Nick Sklavenitis wrote:> > I have noticed as of late that Tom has mentionned that routing support > will be taken outShorewall 1.4 alters the routing table when an entry in /etc/shorewall/proxyarp contains ''No'' in the HAVEROUTE column. This has the unfortunate side effect that the route added at "shorewall start" time is removed at "shorewall stop". In most cases, it is desirable for the route to be present when Shorewall is stopped. In 2.0, the HAVEROUTE column will be eliminated and host routes for Proxy ARP will have to be added outside of Shorewall.> and that from what i have gather no rpm''s will be > released? with future releases or am i mistaken. >I will continue to release RPMs but I will have no way to test them under RedHat software. I will ensure that then install on Mandrake and SuSE (uni-processor). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Monday 26 January 2004 08:33 pm, Lew Newby Jr wrote:> Tom, > I am an experienced user. I have actually enjoyed Shorewall for some > time now (almost 2 years now) as a very useful tool. I have only used it > in a 2 interface configuration and have up to now not had a single > problem. It works. I am faced with having to expand it so I can do my > work from home. Unfortunately the boneheads where I work have a Nortel > VPN solution and I have not been able to get any decent IPSEC tool to > work with their solution so I am left with this netscreen as a solution. > The challenge I have is limited time and I was hoping for some pointers > to either documentation with pseudo examples or some sort of idea on > where to look. You gave me a pointer and I will take it and go off once > more and try to figure it out. > > I know how to make my system route packets to the new interface and I > know how to set it up so it responds through the correct path. The > masquerading /policy/rules is where I get confused when adding in a new > interface. I will be doing two different SNAT setups if my understanding > is correct and I need to route the packet before it goes through the > SNAT so it will get the correct translation. >I''ll assume: eth0 = internet IF eth1 = local IF eth2 = Netscreen IF I''ll further assume that you can configure eth2 with a 139.99 address and get it talking to the netscreen (with Shorewall stopped). /etc/shorewall/zones (add the following) work Work VPN to work /etc/shorewall/interfaces (add the following) work eth2 detect /etc/shorewall/policy (add the following -- I think these are the policies you said you wanted but you can salt to taste...) loc work ACCEPT work loc ACCEPT /etc/shorewall/masq (add the following) eth2 eth1 /etc/shorewall/rules (add these for testing) ACCEPT fw work icmp 8 ACCEPT work fw icmp 8 Now configure eth2 in /etc/network/interfaces to route traffic to your work CLASS B through the netscreen (you mention that you know how to do that) and you are done. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> On Monday 26 January 2004 09:01 pm, Nick Sklavenitis wrote: > >> >> I have noticed as of late that Tom has mentionned that routing support >> will be taken out > > Shorewall 1.4 alters the routing table when an entry in > /etc/shorewall/proxyarp contains ''No'' in the HAVEROUTE column. This has > the > unfortunate side effect that the route added at "shorewall start" time is > removed at "shorewall stop". In most cases, it is desirable for the route > to > be present when Shorewall is stopped. In 2.0, the HAVEROUTE column will be > eliminated and host routes for Proxy ARP will have to be added outside of > Shorewall. > >> and that from what i have gather no rpm''s will be >> released? with future releases or am i mistaken. >> > > I will continue to release RPMs but I will have no way to test them under > RedHat software. I will ensure that then install on Mandrake and SuSE > (uni-processor).Does Fedora count as RedHat software? Simon> > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
On Tuesday 27 January 2004 07:39 am, Simon Matter wrote:> > > > I will continue to release RPMs but I will have no way to test them under > > RedHat software. I will ensure that then install on Mandrake and SuSE > > (uni-processor). > > Does Fedora count as RedHat software? >Yes, but I''m not planning to run Fedora. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tuesday 27 January 2004 08:39 am, Lew Newby Jr wrote:> Bingo, that is perfect. Thank you very very much. I got the routing > handled no problem. >> > > >/etc/shorewall/policy (add the following -- I think these are the policies > > you said you wanted but you can salt to taste...) > > > >loc work ACCEPT > >work loc ACCEPT > >I should also point out that since you are using Masquerading for loc->work, the ACCEPT policy for work->loc doesn''t quite open up connections in that direction. For each work->loc connection type that you wish to accept, you will need to have a DNAT- rule (in addition to the policy) to direct the connections to a particular local host. If you want to have all connections forwarded to a particular local host, you may want to consider configuring eth2 with two 139.99 addresses and using one of those addresses to create one-to-one NAT with that local host. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net