I''m getting my zones confused. Help. I need to have a bunch of systems using OpenVPN to gain an IP in the virtual subnet 10.100.1.0/24, on interface tun0. I will then route whole subnets to those IPs, like 10.100.2.0/24 via 10.100.1.12, etc. I want to have a policy for: - all hosts behind tun0 - all hosts in 10.100.1.0/24 - individual subnets being routed through IPs in 10.100.1.0/24 So, I think I need: interfaces: - tun0 hosts: remote1 tun0:10.100.2.0/24 routers tun0:10.100.1.0/24 remote tun0:0.0.0.0/8 zones: remote1 routes remote In rules & policy I would list rules in order by remote1, routers, remote. Does this seem correct? Where do I put the routeback so that routers can see each other? Thanks, A.
Adam Sherman wrote:> I''m getting my zones confused. Help. > > I need to have a bunch of systems using OpenVPN to gain an IP in the > virtual subnet 10.100.1.0/24, on interface tun0. > > I will then route whole subnets to those IPs, like 10.100.2.0/24 via > 10.100.1.12, etc. > > I want to have a policy for: > > - all hosts behind tun0 > - all hosts in 10.100.1.0/24 > - individual subnets being routed through IPs in 10.100.1.0/24 > > So, I think I need: > > interfaces: > > - tun0 > > hosts: > > remote1 tun0:10.100.2.0/24 > routers tun0:10.100.1.0/24 > remote tun0:0.0.0.0/8 > > zones: > > remote1 > routes > remote > > In rules & policy I would list rules in order by remote1, routers, remote.The order of entries in the rules and policy files is irrelevant in this discussion (as is the order of entries in /etc/shorewall/hosts).> > Does this seem correct? > > Where do I put the routeback so that routers can see each other? >First of all, you need to read the comments at the top of your /etc/shorewall/zones file carefully -- they mention that the order of zone definitions is critical when you have nested and/or overlapping zones. They also refer you to a URL where that topic is discussed further -- in particular, it speaks about CONTINUE policies which you may find useful. Secondly, if you want to have shorewall route between the hosts in the ''routers'' zone then you put ''routeback'' on that zone''s entry in /etc/shorewall/hosts. -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
Tom Eastep wrote:>>interfaces: >> >>- tun0 >> >>hosts: >> >>remote1 tun0:10.100.2.0/24 >>routers tun0:10.100.1.0/24 >>remote tun0:0.0.0.0/8 >> >>zones: >> >>remote1 >>routers >>remote> First of all, you need to read the comments at the top of your > /etc/shorewall/zones file carefully -- they mention that the order of > zone definitions is critical when you have nested and/or overlapping > zones. They also refer you to a URL where that topic is discussed > further -- in particular, it speaks about CONTINUE policies which you > may find useful.I''ve read the above and understand that the order in zones should be from most-sepcific to least-specific, which I''ve done.> Secondly, if you want to have shorewall route between the hosts in the > ''routers'' zone then you put ''routeback'' on that zone''s entry in > /etc/shorewall/hosts.I hadn''t clued into routeback being possible anywhere other than interfaces. Thanks. Pinging 10.100.1.1 from 10.100.1.6 is getting dropped in the all2all chain, when I really want it in the routers2fw chain. I notice also that the OUT is empty, is this because of routeback? Shorewall:all2all:DROP:IN=tun0 OUT= MAC= SRC=10.100.1.6 DST=10.100.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=ICMP TYPE=8 CODE=0 ID=27671 SEQ=4 Before adding my entire config to the post, what does traffic being dropped in the wrond chain indicate, simply that it fell through to this chain because I didn''t catch it anywhere else? Thanks, A.
Adam Sherman wrote:> Before adding my entire config to the post, what does traffic being > dropped in the wrond chain indicate, simply that it fell through to this > chain because I didn''t catch it anywhere else?Ok, I''m getting the hang of this. I think I''ve got it figured out. Thanks, A.
Adam Sherman wrote:> > Pinging 10.100.1.1 from 10.100.1.6 is getting dropped in the all2all > chain, when I really want it in the routers2fw chain. I notice also that > the OUT is empty, is this because of routeback? > > Shorewall:all2all:DROP:IN=tun0 OUT= MAC= SRC=10.100.1.6 DST=10.100.1.1 > LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=ICMP TYPE=8 CODE=0 > ID=27671 SEQ=4No -- it''s because 10.100.1.1 is an address that is local to the firewall.> > Before adding my entire config to the post, what does traffic being > dropped in the wrond chain indicate, simply that it fell through to this > chain because I didn''t catch it anywhere else?Only if you are using CONTINUE policies. -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
Adam Sherman wrote:>> Before adding my entire config to the post, what does traffic being >> dropped in the wrond chain indicate, simply that it fell through to >> this chain because I didn''t catch it anywhere else? > > Ok, I''m getting the hang of this. I think I''ve got it figured out.Almost. :-) I needed to re-read the bit about CONTINUE. In a nested zone situation where you want to be able to apply policy to the superset, and override it for a subset, you need something like this in policy: net sub1 CONTINUE net sub2 CONTINUE net subn CONTINUE net super REJECT Then a rule in rules: AllowPing net super Would allow net to ping the whole superset while a rule like: AllowPing net sub Would only affect the subset. This is probably a common setup. In policy, I have: brds fw CONTINUE brds loc CONTINUE vpn fw REJECT vpn loc REJECT (Where brds are the routers and vpn whould encapsulate all hosts on interface tun0.) I''m getting a DROP in the INPUT chain, which according to FAQ17 means that the source IP is not in any zone. According to shorewall check, it should be in brds & then also in vpn. This is 2.2.0-RC3. Shorewall:INPUT:DROP:IN=tun0 OUT= MAC= SRC=10.100.1.6 DST=10.100.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=29207 SEQ=1 hosts has: brds tun0:10.100.1.0/24 routeback vpn tun0:0.0.0.0/8 routeback (Also, could the vpn line in hosts be replaced by a line in interfaces?) Thanks, A.
Tom Eastep wrote:>>chain, when I really want it in the routers2fw chain. I notice also that >>the OUT is empty, is this because of routeback? >> >>Shorewall:all2all:DROP:IN=tun0 OUT= MAC= SRC=10.100.1.6 DST=10.100.1.1 >>LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=ICMP TYPE=8 CODE=0 >>ID=27671 SEQ=4 > > No -- it''s because 10.100.1.1 is an address that is local to the firewall.Ah, of course. My dumb question. :-) A.
Adam Sherman wrote:> Adam Sherman wrote: > >>> Before adding my entire config to the post, what does traffic being >>> dropped in the wrond chain indicate, simply that it fell through to >>> this chain because I didn''t catch it anywhere else? >> >> >> Ok, I''m getting the hang of this. I think I''ve got it figured out. > > > Almost. :-) > > I needed to re-read the bit about CONTINUE. In a nested zone situation > where you want to be able to apply policy to the superset, and override > it for a subset, you need something like this in policy: > > net sub1 CONTINUE > net sub2 CONTINUE > net subn CONTINUE > net super REJECT > > Then a rule in rules: > > AllowPing net super > > Would allow net to ping the whole superset while a rule like: > > AllowPing net sub > > Would only affect the subset. > > This is probably a common setup. > > In policy, I have: > > brds fw CONTINUE > brds loc CONTINUE > vpn fw REJECT > vpn loc REJECT > > (Where brds are the routers and vpn whould encapsulate all hosts on > interface tun0.) > > I''m getting a DROP in the INPUT chain, which according to FAQ17 means > that the source IP is not in any zone. According to shorewall check, it > should be in brds & then also in vpn. This is 2.2.0-RC3. > > Shorewall:INPUT:DROP:IN=tun0 OUT= MAC= SRC=10.100.1.6 DST=10.100.1.1 > LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 > ID=29207 SEQ=1 > > hosts has: > > brds tun0:10.100.1.0/24 routeback > vpn tun0:0.0.0.0/8 routebackSurely not.... 0.0.0.0/8 ?????????> > (Also, could the vpn line in hosts be replaced by a line in interfaces?) >Yes -- if what you really meant was 0.0.0.0/0. -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
Tom Eastep wrote:>>hosts has: >> >>brds tun0:10.100.1.0/24 routeback >>vpn tun0:0.0.0.0/8 routeback > > Surely not.... 0.0.0.0/8 ?????????Uh, yeah, that would do it. Damn. Sorry!>>(Also, could the vpn line in hosts be replaced by a line in interfaces?) > > Yes -- if what you really meant was 0.0.0.0/0.Is there a difference between declaring a zone in hosts like eth0:0.0.0.0/0 versus declaring it in interfaces? Thanks, A.
Adam Sherman wrote:> > > Is there a difference between declaring a zone in hosts like > eth0:0.0.0.0/0 versus declaring it in interfaces?No. -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