In the panic of replacing our firewall(s) earlier in the week, we ended up moving our original shorewall 1.4 config onto a machine with 2.0.10 already installed, overwriting all the 2.0.10 config files. Most things seem to work fine, except for our masq entries. I''ve examined the default 2.0.10 files compared with our 1.4 files, and can''t spot the problem. What am I missing? Here''s the revelant info (I think): zones: net Net Internet sls sls SLS network interfaces: sls eth0 detect routefilter net eth1 detect routefilter,tcpflags shorewall.conf: ADD_IP_ALIASES=Yes ADD_SNAT_ALIASES=No masq: eth1 10.2.200.0/24 - eth1 139.142.66.4/32 139.142.65.146 eth1 10.2.250.0/24 139.142.65.146 eth1 10.2.220.0/24 139.142.65.146 eth1 10.2.201.0/24 139.142.65.146 one of the relevant lines in rules: ACCEPT sls net tcp 110 - 139.142.65.146 is the ip of eth1 The 2nd line of masq used to provided masq for 139.142.66.4, but now it simply routes it through when permitted in rules, since this IP is routable. Of course, the rest are not, so they don''t go anywhere... Is there a quick fix to this? I know, I should RTFM, but I tried that, and my brain is mush right now due to lack of sleep/too much coffee. :-( Thx. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
On Fri, 2004-11-19 at 16:04 -0800, Shawn Wright wrote:> Here''s the revelant info (I think): > > zones: > net Net Internet > sls sls SLS network > > interfaces: > sls eth0 detect routefilter > net eth1 detect routefilter,tcpflags > > shorewall.conf: > ADD_IP_ALIASES=Yes > ADD_SNAT_ALIASES=No > > masq: > eth1 10.2.200.0/24 - > eth1 139.142.66.4/32 139.142.65.146 > eth1 10.2.250.0/24 139.142.65.146 > eth1 10.2.220.0/24 139.142.65.146 > eth1 10.2.201.0/24 139.142.65.146 > > one of the relevant lines in rules: > ACCEPT sls net tcp 110 - > > 139.142.65.146 is the ip of eth1 > The 2nd line of masq used to provided masq for 139.142.66.4, but now it > simply routes it through when permitted in rules, since this IP is routable. > Of course, the rest are not, so they don''t go anywhere... > > Is there a quick fix to this? I know, I should RTFM, but I tried that, and my > brain is mush right now due to lack of sleep/too much coffee. :-(Given the above information, I have no idea what is causing the problem. What does "shorewall show nat" show? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On 19 Nov 2004 at 16:25, Tom Eastep wrote:> On Fri, 2004-11-19 at 16:04 -0800, Shawn Wright wrote: > > > Here''s the revelant info (I think): > > > > zones: > > net Net Internet > > sls sls SLS network > > > > interfaces: > > sls eth0 detect routefilter > > net eth1 detect routefilter,tcpflags > > > > shorewall.conf: > > ADD_IP_ALIASES=Yes > > ADD_SNAT_ALIASES=No > > > > masq: > > eth1 10.2.200.0/24 - > > eth1 139.142.66.4/32 139.142.65.146 > > eth1 10.2.250.0/24 139.142.65.146 > > eth1 10.2.220.0/24 139.142.65.146 > > eth1 10.2.201.0/24 139.142.65.146 > > > > one of the relevant lines in rules: > > ACCEPT sls net tcp 110 - > > > > 139.142.65.146 is the ip of eth1 > > The 2nd line of masq used to provided masq for 139.142.66.4, but now it > > simply routes it through when permitted in rules, since this IP is routable. > > Of course, the rest are not, so they don''t go anywhere... > > > > Is there a quick fix to this? I know, I should RTFM, but I tried that, and my > > brain is mush right now due to lack of sleep/too much coffee. :-( > > Given the above information, I have no idea what is causing the problem. > What does "shorewall show nat" show?I''m puzzled as well. I double checked the kernel has NAT compiled in, and it does. I imagine shorewall would have complained if it didn''t. Here''s the shorewall show nat output: Shorewall-2.0.10 NAT at proxy4.sls.bc.ca - Fri Nov 19 16:28:59 PST 2004 Counters reset Fri Nov 19 14:26:24 PST 2004 Chain PREROUTING (policy ACCEPT 1723K packets, 103M bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 785K packets, 43M bytes) pkts bytes target prot opt in out source destination 50519 2697K eth1_masq all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 472 packets, 35708 bytes) pkts bytes target prot opt in out source destination Chain eth1_masq (1 references) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * * 10.2.200.0/24 0.0.0.0/0 0 0 SNAT all -- * * 139.142.66.4 0.0.0.0/0 to:139.142.65.146 0 0 SNAT all -- * * 10.2.250.0/24 0.0.0.0/0 to:139.142.65.146 0 0 SNAT all -- * * 10.2.220.0/24 0.0.0.0/0 to:139.142.65.146 0 0 SNAT all -- * * 10.2.201.0/24 0.0.0.0/0 to:139.142.65.146 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
On Fri, 2004-11-19 at 17:01 -0800, Shawn Wright wrote:> On 19 Nov 2004 at 16:25, Tom Eastep wrote:> > Given the above information, I have no idea what is causing the problem. > > What does "shorewall show nat" show? > > I''m puzzled as well. I double checked the kernel has NAT compiled in, > and it does. I imagine shorewall would have complained if it didn''t.Actually, iptables would have complained.> Here''s the shorewall show nat output: > > Shorewall-2.0.10 NAT at proxy4.sls.bc.ca - Fri Nov 19 16:28:59 PST 2004 > > Counters reset Fri Nov 19 14:26:24 PST 2004 > > Chain PREROUTING (policy ACCEPT 1723K packets, 103M bytes) > pkts bytes target prot opt in out source destination > > Chain POSTROUTING (policy ACCEPT 785K packets, 43M bytes) > pkts bytes target prot opt in out source destination > 50519 2697K eth1_masq all -- * eth1 0.0.0.0/0 0.0.0.0/0 > > Chain OUTPUT (policy ACCEPT 472 packets, 35708 bytes) > pkts bytes target prot opt in out source destination > > Chain eth1_masq (1 references) > pkts bytes target prot opt in out source destination > 0 0 MASQUERADE all -- * * 10.2.200.0/24 0.0.0.0/0 > 0 0 SNAT all -- * * 139.142.66.4 0.0.0.0/0 > to:139.142.65.146The above rule says that any connection requests with a source of 139.142.66.4 will have the source changes to 139.142.65.146. So I don''t understand how you could be seeing the results you report. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
This gets more puzzling. I have now switched back to the original firewall,
still running Shorewall 1.4.8, but I compile a 2.4.22 kernel for it.
Otherwise, it is unchanged from several weeks back, and NAT now works
as it used to. Below is the output from shorewall show nat. I don''t see
any
differences...
Shorewall-1.4.8 NAT at fw.sls.bc.ca - Thu Nov 25 08:37:32 PST 2004
Counters reset Wed Nov 24 21:59:27 PST 2004
Chain PREROUTING (policy ACCEPT 586K packets, 35M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 335K packets, 17M bytes)
pkts bytes target prot opt in out source destination
114K 5683K eth1_masq all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 147 packets, 10513 bytes)
pkts bytes target prot opt in out source destination
Chain eth1_masq (1 references)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * * 10.2.200.0/24 0.0.0.0/0
to:139.142.65.146
234 10574 SNAT all -- * * 139.142.66.4 0.0.0.0/0
to:139.142.65.146
0 0 SNAT all -- * * 10.2.250.0/24 0.0.0.0/0
to:139.142.65.146
0 0 SNAT all -- * * 10.2.220.0/24 0.0.0.0/0
to:139.142.65.146
0 0 SNAT all -- * * 10.2.201.0/24 0.0.0.0/0
to:139.142.65.146
On 19 Nov 2004 at 17:09, Tom Eastep wrote:
> On Fri, 2004-11-19 at 17:01 -0800, Shawn Wright wrote:
> > On 19 Nov 2004 at 16:25, Tom Eastep wrote:
>
> > > Given the above information, I have no idea what is causing the
problem.
> > > What does "shorewall show nat" show?
> >
> > I''m puzzled as well. I double checked the kernel has NAT
compiled in,
> > and it does. I imagine shorewall would have complained if it
didn''t.
>
> Actually, iptables would have complained.
>
> > Here''s the shorewall show nat output:
> >
> > Shorewall-2.0.10 NAT at proxy4.sls.bc.ca - Fri Nov 19 16:28:59 PST
2004
> >
> > Counters reset Fri Nov 19 14:26:24 PST 2004
> >
> > Chain PREROUTING (policy ACCEPT 1723K packets, 103M bytes)
> > pkts bytes target prot opt in out source
destination
> >
> > Chain POSTROUTING (policy ACCEPT 785K packets, 43M bytes)
> > pkts bytes target prot opt in out source
destination
> > 50519 2697K eth1_masq all -- * eth1 0.0.0.0/0
0.0.0.0/0
> >
> > Chain OUTPUT (policy ACCEPT 472 packets, 35708 bytes)
> > pkts bytes target prot opt in out source
destination
> >
> > Chain eth1_masq (1 references)
> > pkts bytes target prot opt in out source
destination
> > 0 0 MASQUERADE all -- * * 10.2.200.0/24
0.0.0.0/0
> > 0 0 SNAT all -- * * 139.142.66.4
0.0.0.0/0
> > to:139.142.65.146
>
> The above rule says that any connection requests with a source of
> 139.142.66.4 will have the source changes to 139.142.65.146.
>
> So I don''t understand how you could be seeing the results you
report.
>
> -Tom
> --
> Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
> Shoreline, \ http://shorewall.net
> Washington USA \ teastep@shorewall.net
> PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
>
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Shawn Wright, I.T. Manager
Shawnigan Lake School
http://www.sls.bc.ca
swright@sls.bc.ca
On Thu, 2004-11-25 at 08:41 -0800, Shawn Wright wrote:> This gets more puzzling. I have now switched back to the original firewall, > still running Shorewall 1.4.8, but I compile a 2.4.22 kernel for it. > Otherwise, it is unchanged from several weeks back, and NAT now works > as it used to. Below is the output from shorewall show nat. I don''t see any > differences...Nor do I. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key