> DNAT:info net:192.168.10.0/24 net:192.168.241.65 all - > - 192.168.20.33 > > But for that packets to go to 192.168.241.65 the source must be also > rewritten to 196.44.33.118. > > Any ideas?>In Shorewall, all source address rewriting is accomplished using entries in/etc/shorewall/masq. I have added the following line: /etc/shorewall/masq eth0:192.168.241.65 192.168.10.0/24 196.44.33.118 But this line/rules is not implemented correctly. The DNAT happens, but not the SNAT. In what following is DNAT and SNAT rules applied? Regards Jan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jan van der Vyver wrote:>> DNAT:info net:192.168.10.0/24 net:192.168.241.65 all - >> - 192.168.20.33 >> >> But for that packets to go to 192.168.241.65 the source must be also >> rewritten to 196.44.33.118. >> >> Any ideas? > >> In Shorewall, all source address rewriting is accomplished using entries in > /etc/shorewall/masq. > > I have added the following line: > > /etc/shorewall/masq > eth0:192.168.241.65 192.168.10.0/24 196.44.33.118 > > But this line/rules is not implemented correctly. > > The DNAT happens, but not the SNAT. > > In what following is DNAT and SNAT rules applied? >DNAT is applied before SNAT. And if you have more problems, please include a dump (see http://www.shorewall.net/support.htm#Guidelines). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> DNAT:info net:192.168.10.0/24 net:192.168.241.65 all - >> - 192.168.20.33 >> >> But for that packets to go to 192.168.241.65 the source must be also >> rewritten to 196.44.33.118. >> >> Any ideas? > >> In Shorewall, all source address rewriting is accomplished using >> entries in > /etc/shorewall/masq. > > I have added the following line: > > /etc/shorewall/masq > eth0:192.168.241.65 192.168.10.0/24 196.44.33.118 > > But this line/rules is not implemented correctly. > > The DNAT happens, but not the SNAT. > > In what following is DNAT and SNAT rules applied? >>DNAT is applied before SNAT.>And if you have more problems, please include a dump (seehttp://www.shorewall.net/support.htm#Guidelines). Sorry Version: 3.0.4 (Ubuntu dapper package) ip addr show: 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:13:72:3f:74:20 brd ff:ff:ff:ff:ff:ff inet 196.44.33.187/29 brd 196.44.33.191 scope global eth0 inet 196.44.33.118/32 scope global eth0 inet 196.44.33.190/29 scope global secondary eth0:0 inet6 fe80::213:72ff:fe3f:7420/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:72:3f:74:21 brd ff:ff:ff:ff:ff:ff inet 192.168.199.1/24 brd 192.168.199.255 scope global eth1 inet6 fe80::213:72ff:fe3f:7421/64 scope link valid_lft forever preferred_lft forever 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 link/[65534] inet 192.168.20.1 peer 192.168.20.2/32 scope global tun0 ip route show: 192.168.1.253 dev eth0 scope link 192.168.20.2 dev tun0 proto kernel scope link src 192.168.20.1 192.168.241.65 dev eth0 scope link 196.44.33.184/29 dev eth0 proto kernel scope link src 196.44.33.187 192.168.20.0/27 via 192.168.20.2 dev tun0 192.168.199.0/24 dev eth1 proto kernel scope link src 192.168.199.1 192.168.10.0/24 dev eth0 scope link default via 196.44.33.185 dev eth0>From the logs on Machine B:Oct 9 20:58:16 neon kernel: [43844718.340000] Shorewall:net_dnat:DNAT:IN=eth0 OUTMAC=00:13:72:3f:74:20:00:12:00:6c:ea:d0:08:00 SRC=192.168.10.198 DST=192.168.20.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42453 DF PROTO=TCP SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 9 20:58:16 neon kernel: [43844718.340000] Shorewall:net2all:DROP:IN=eth0 OUT=eth0 SRC=192.168.10.198 DST=192.168.241.65 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42453 DF PROTO=TCP SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Thank you for your help Tom. Regards Jan van der Vyver ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jan van der Vyver wrote:> >>> DNAT:info net:192.168.10.0/24 net:192.168.241.65 all - >>> - 192.168.20.33 >>> >>> But for that packets to go to 192.168.241.65 the source must be also >>> rewritten to 196.44.33.118. >>> >>> Any ideas? >>> In Shorewall, all source address rewriting is accomplished using >>> entries in >> /etc/shorewall/masq. >> >> I have added the following line: >> >> /etc/shorewall/masq >> eth0:192.168.241.65 192.168.10.0/24 196.44.33.118 >> >> But this line/rules is not implemented correctly. >> >> The DNAT happens, but not the SNAT. >> >> In what following is DNAT and SNAT rules applied? >> > >> DNAT is applied before SNAT. > >> And if you have more problems, please include a dump (see > http://www.shorewall.net/support.htm#Guidelines). > > Sorry > > Version: > > 3.0.4 (Ubuntu dapper package) > > ip addr show: > > 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:13:72:3f:74:20 brd ff:ff:ff:ff:ff:ff > inet 196.44.33.187/29 brd 196.44.33.191 scope global eth0 > inet 196.44.33.118/32 scope global eth0 > inet 196.44.33.190/29 scope global secondary eth0:0 > inet6 fe80::213:72ff:fe3f:7420/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:13:72:3f:74:21 brd ff:ff:ff:ff:ff:ff > inet 192.168.199.1/24 brd 192.168.199.255 scope global eth1 > inet6 fe80::213:72ff:fe3f:7421/64 scope link > valid_lft forever preferred_lft forever > 4: sit0: <NOARP> mtu 1480 qdisc noop > link/sit 0.0.0.0 brd 0.0.0.0 > 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc pfifo_fast > qlen 100 > link/[65534] > inet 192.168.20.1 peer 192.168.20.2/32 scope global tun0 > > ip route show: > > 192.168.1.253 dev eth0 scope link > 192.168.20.2 dev tun0 proto kernel scope link src 192.168.20.1 > 192.168.241.65 dev eth0 scope link > 196.44.33.184/29 dev eth0 proto kernel scope link src 196.44.33.187 > 192.168.20.0/27 via 192.168.20.2 dev tun0 > 192.168.199.0/24 dev eth1 proto kernel scope link src 192.168.199.1 > 192.168.10.0/24 dev eth0 scope link > default via 196.44.33.185 dev eth0 > > >>From the logs on Machine B: > > Oct 9 20:58:16 neon kernel: [43844718.340000] > Shorewall:net_dnat:DNAT:IN=eth0 OUT> MAC=00:13:72:3f:74:20:00:12:00:6c:ea:d0:08:00 SRC=192.168.10.198 > DST=192.168.20.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42453 DF PROTO=TCP > SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 > Oct 9 20:58:16 neon kernel: [43844718.340000] > Shorewall:net2all:DROP:IN=eth0 OUT=eth0 SRC=192.168.10.198 > DST=192.168.241.65 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42453 DF PROTO=TCP > SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 > > Thank you for your help Tom.Jan -- you are having a connection problem. I need you to: a) shorewall reset b) Try the connection that isn''t working (where the source IP address is not being rewritten) c) shorewall dump > dump.txt d) Send me the dump.txt file along with the client IP address, the server IP address, protocol and port number (or tell me that it is SSH). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>> DNAT:info net:192.168.10.0/24 net:192.168.241.65 all->>> - 192.168.20.33 >>> >>> But for that packets to go to 192.168.241.65 the source must be also >>> rewritten to 196.44.33.118. >>> >>> Any ideas? >>> In Shorewall, all source address rewriting is accomplished using >>> entries in >> /etc/shorewall/masq. >> >> I have added the following line: >> >> /etc/shorewall/masq >> eth0:192.168.241.65 192.168.10.0/24 196.44.33.118 >> >> But this line/rules is not implemented correctly. >> >> The DNAT happens, but not the SNAT. >> >> In what following is DNAT and SNAT rules applied? >> > >> DNAT is applied before SNAT. > >> And if you have more problems, please include a dump (see > http://www.shorewall.net/support.htm#Guidelines). > > Sorry > > Version: > > 3.0.4 (Ubuntu dapper package) > > ip addr show: > > 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:13:72:3f:74:20 brd ff:ff:ff:ff:ff:ff > inet 196.44.33.187/29 brd 196.44.33.191 scope global eth0 > inet 196.44.33.118/32 scope global eth0 > inet 196.44.33.190/29 scope global secondary eth0:0 > inet6 fe80::213:72ff:fe3f:7420/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen1000> link/ether 00:13:72:3f:74:21 brd ff:ff:ff:ff:ff:ff > inet 192.168.199.1/24 brd 192.168.199.255 scope global eth1 > inet6 fe80::213:72ff:fe3f:7421/64 scope link > valid_lft forever preferred_lft forever > 4: sit0: <NOARP> mtu 1480 qdisc noop > link/sit 0.0.0.0 brd 0.0.0.0 > 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc > pfifo_fast qlen 100 > link/[65534] > inet 192.168.20.1 peer 192.168.20.2/32 scope global tun0 > > ip route show: > > 192.168.1.253 dev eth0 scope link > 192.168.20.2 dev tun0 proto kernel scope link src 192.168.20.1 > 192.168.241.65 dev eth0 scope link > 196.44.33.184/29 dev eth0 proto kernel scope link src 196.44.33.187 > 192.168.20.0/27 via 192.168.20.2 dev tun0 > 192.168.199.0/24 dev eth1 proto kernel scope link src 192.168.199.1 > 192.168.10.0/24 dev eth0 scope link > default via 196.44.33.185 dev eth0 > > >>From the logs on Machine B: > > Oct 9 20:58:16 neon kernel: [43844718.340000] > Shorewall:net_dnat:DNAT:IN=eth0 OUT= > MAC=00:13:72:3f:74:20:00:12:00:6c:ea:d0:08:00 SRC=192.168.10.198 > DST=192.168.20.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42453 DF > PROTO=TCP > SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 9 20:58:16 neon > kernel: [43844718.340000] Shorewall:net2all:DROP:IN=eth0 OUT=eth0 > SRC=192.168.10.198 > DST=192.168.241.65 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42453 DF > PROTO=TCP > SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 > > Thank you for your help Tom.>Jan -- you are having a connection problem. I need you to:>a) shorewall reset >b) Try the connection that isn''t working (where the source IP address isnot being rewritten)>c) shorewall dump > dump.txt >d) Send me the dump.txt file along with the client IP address, the serverIP address, protocol and port number (or tell me that it is SSH). I am trying to ssh from a machine (192.168.10.198) behind machine A (192.168.10.200) to 192.168.20.33. Between machine A and machine B there is a ipsec vpn. Config for this vpn: conn in2one-to-adept type=tunnel connaddrfamily=ipv4 left=196.44.33.190 leftnexthop=%direct leftsubnet=192.168.20.0/24 leftid=neon@adept leftrsasigkey=bla right=196.44.33.114 rightnexthop=%direct rightsubnet=192.168.10.0/24 rightid=fw@in2one rightrsasigkey=bla auto=start Then machine B must rewrite any packets (on all ports) to 192.168.20.33 ,the destination to 192.168.241.65 and the source to 196.44.33.118 Between machine B and C is a ipsec vpn: Config: conn obw type=tunnel connaddrfamily=ipv4 left=196.44.33.190 leftnexthop=%direct leftsubnet=196.44.33.118/32 right=168.167.251.89 rightnexthop=%direct rightsubnet=192.168.241.65/32 rightid=193.219.215.3 authby=secret esp=3des-md5-96 #esp=3des-md5 keyexchange=ike pfs=no auto=start If I ssh from from machine b with the following: ssh -b 196.44.33.118 jan@192.168.241.65 It works. If I ssh from 192.168.10.198 then the following is seen on machine B''s syslog> Shorewall:net_dnat:DNAT:IN=eth0 OUT= > MAC=00:13:72:3f:74:20:00:12:00:6c:ea:d0:08:00 SRC=192.168.10.198 > DST=192.168.20.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42453 DF > PROTO=TCP > SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 9 20:58:16 neon > kernel: [43844718.340000] Shorewall:net2all:DROP:IN=eth0 OUT=eth0 > SRC=192.168.10.198 > DST=192.168.241.65 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42453 DF > PROTO=TCP > SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0Hope this make it more clear. Let me know If I can give anymore information. Regards Jan van der Vyver ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jan van der Vyver wrote:> I am trying to ssh from a machine (192.168.10.198) behind machine A > (192.168.10.200) to 192.168.20.33. > > Between machine A and machine B there is a ipsec vpn. > Config for this vpn: > > conn in2one-to-adept > type=tunnel > connaddrfamily=ipv4 > left=196.44.33.190 > leftnexthop=%direct > leftsubnet=192.168.20.0/24 > leftid=neon@adept > leftrsasigkey=bla > right=196.44.33.114 > rightnexthop=%direct > rightsubnet=192.168.10.0/24 > rightid=fw@in2one > rightrsasigkey=bla > auto=start > > Then machine B must rewrite any packets (on all ports) to 192.168.20.33 ,the > destination to 192.168.241.65 and the source to 196.44.33.118 > > Between machine B and C is a ipsec vpn: > Config: > conn obw > type=tunnel > connaddrfamily=ipv4 > left=196.44.33.190 > leftnexthop=%direct > leftsubnet=196.44.33.118/32 > right=168.167.251.89 > rightnexthop=%direct > rightsubnet=192.168.241.65/32 > rightid=193.219.215.3 > authby=secret > esp=3des-md5-96 > #esp=3des-md5 > keyexchange=ike > pfs=no > auto=start > > If I ssh from from machine b with the following: > > ssh -b 196.44.33.118 jan@192.168.241.65 > > It works. > > If I ssh from 192.168.10.198 then the following is seen on machine B''s > syslog > >> Shorewall:net_dnat:DNAT:IN=eth0 OUT= >> MAC=00:13:72:3f:74:20:00:12:00:6c:ea:d0:08:00 SRC=192.168.10.198 >> DST=192.168.20.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42453 DF >> PROTO=TCP >> SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 9 20:58:16 neon >> kernel: [43844718.340000] Shorewall:net2all:DROP:IN=eth0 OUT=eth0 >> SRC=192.168.10.198 >> DST=192.168.241.65 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42453 DF >> PROTO=TCP >> SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 > > Hope this make it more clear. >Ok. You do not have IPSEC policy match enabled (although your kernel is new enough to support it). You must enable it if you want this to work; then follow the instructions in http://www.shorewall.net/IPSEC-2.6.html. Without policy match, SNAT rules are not applied until after the traffic is encrypted and encapsulated; by that time, it is too late to change the original SOURCE IP address. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Jan van der Vyver wrote: > >> I am trying to ssh from a machine (192.168.10.198) behind machine A >> (192.168.10.200) to 192.168.20.33. >> >> Between machine A and machine B there is a ipsec vpn. >> Config for this vpn: >> >> conn in2one-to-adept >> type=tunnel >> connaddrfamily=ipv4 >> left=196.44.33.190 >> leftnexthop=%direct >> leftsubnet=192.168.20.0/24 >> leftid=neon@adept >> leftrsasigkey=bla >> right=196.44.33.114 >> rightnexthop=%direct >> rightsubnet=192.168.10.0/24 >> rightid=fw@in2one >> rightrsasigkey=bla >> auto=start >> >> Then machine B must rewrite any packets (on all ports) to 192.168.20.33 ,the >> destination to 192.168.241.65 and the source to 196.44.33.118 >> >> Between machine B and C is a ipsec vpn: >> Config: >> conn obw >> type=tunnel >> connaddrfamily=ipv4 >> left=196.44.33.190 >> leftnexthop=%direct >> leftsubnet=196.44.33.118/32 >> right=168.167.251.89 >> rightnexthop=%direct >> rightsubnet=192.168.241.65/32 >> rightid=193.219.215.3 >> authby=secret >> esp=3des-md5-96 >> #esp=3des-md5 >> keyexchange=ike >> pfs=no >> auto=start >> >> If I ssh from from machine b with the following: >> >> ssh -b 196.44.33.118 jan@192.168.241.65 >> >> It works. >> >> If I ssh from 192.168.10.198 then the following is seen on machine B''s >> syslog >> >>> Shorewall:net_dnat:DNAT:IN=eth0 OUT= >>> MAC=00:13:72:3f:74:20:00:12:00:6c:ea:d0:08:00 SRC=192.168.10.198 >>> DST=192.168.20.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42453 DF >>> PROTO=TCP >>> SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 9 20:58:16 neon >>> kernel: [43844718.340000] Shorewall:net2all:DROP:IN=eth0 OUT=eth0 >>> SRC=192.168.10.198 >>> DST=192.168.241.65 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42453 DF >>> PROTO=TCP >>> SPT=60171 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 >> Hope this make it more clear. >> > > Ok. > > You do not have IPSEC policy match enabled (although your kernel is new enough > to support it). You must enable it if you want this to work; then follow the > instructions in http://www.shorewall.net/IPSEC-2.6.html. > > Without policy match, SNAT rules are not applied until after the traffic is > encrypted and encapsulated; by that time, it is too late to change the original > SOURCE IP address.I got a bit ahead of myself -- I''m correct that to do this right, you need policy match. But you should be able to get it to work if we can determine why your ruleset drops most traffic to/from 192.168.241.65. Please send me a tar-ball of your /etc/shorewall/ directory. Thanks, -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> > I got a bit ahead of myself -- I''m correct that to do this right, you need > policy match. But you should be able to get it to work if we can determine why > your ruleset drops most traffic to/from 192.168.241.65. Please send me a > tar-ball of your /etc/shorewall/ directory. >Ah -- I see. eth0:192.168.241.65 is a zone called ''obo''. And there is no net->obo policy; neither are there any net2obo rules. Consequently all net->obo traffic is being dropped under the net->all DROP policy. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > I got a bit ahead of myself -- I''m correct that to do this right, you > need policy match. But you should be able to get it to work if we can > determine why your ruleset drops most traffic to/from 192.168.241.65. > Please send me a tar-ball of your /etc/shorewall/ directory. >>Ah -- I see. eth0:192.168.241.65 is a zone called ''obo''. And there is no >net->obo policy; neither are there any net2obo rules.>Consequently all net->obo traffic is being dropped under the net->all DROPpolicy. Tom, this last one hit the nail on the head. Added the following rule: ACCEPT net:192.168.10.0/24 obo all And now things work. Thank you for all your help, you solved a problem that I struggled with for weeks. Regards Jan van der Vyver ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV