On 2/25/11 11:30 AM, Paolo Andretta wrote: > On Thu, 24 Feb 2011, Tom Eastep wrote: > >>>> Would something roughly as documented here: >>>> http://www.shorewall.net/FAQ.htm#faq2 help? >>> >>> As in the subject and in my explanation (my english is poor but hope >>> unsterstandable), I read Faq 2 and related docs. I missed something? >> >> Apparently you have since it doesn't work. But until you show us what >> you have done, we can't tell you what you are missing. >> >> Things to check: >> >> a) That you have set 'routeback' on the internal firewall interface. >> b) That you have added a hairpin DNAT rule. >> c) That you have added a hairpin SNAT entry in /etc/shorewall/masq >> d) That all of the addresses in the entries are correct. > > I think address are correct because it is all working fine a part the > "routeback". > > I have (actually, done some tests ...): > > #/etc/shorewall/interfaces > net vmbr0 detect dhcp,tcpflags,logmartians,nosmurfs > dmz vmbr8 detect tcpflags,nosmurfs,routefilter,routeback > dmz vmbr9 detect tcpflags,nosmurfs,routefilter,routeback > dmz vmbr10 detect tcpflags,nosmurfs,routefilter,routeback > loc vmtab+ detect tcpflags,nosmurfs,routefilter > loc vmbr2 detect tcpflags,nosmurfs,routefilter > dmz tap+ detect tcpflags,nosmurfs,routefilter > > #/etc/shorewall/masq > > vmbr0 vmbr9 1.2.3.109 > vmbr0 vmbr10 1.2.3.110 > vmbr0 vmbr8 1.2.3.108
Please get rid of the interface names in the SOURCE column. You must be running some ancient version of Shorewall that doesn't issue a warning for that archaic usage. And I don't see any SNAT rule for dmz->dmz traffic. > > #/etc/shorewall/policy > $FW net ACCEPT > loc net ACCEPT > loc $FW ACCEPT > dmz net ACCEPT > ###dmz $FW ACCEPT > ###dmz dmz ACCEPT > net all DROP info > # The FOLLOWING POLICY MUST BE LAST > all all REJECT info > > #/etc/shorewall/rules > DNAT net dmz:192.168.109.9 tcp 20,21,80,443 - 1.2.3.109 > DNAT net dmz:192.168.110.10 tcp 20,21,80,443 - 1.2.3.110 > DNAT net dmz:192.168.108.8 tcp 20,21,80,443 - 1.2.3.108 I see no dmz->dmz DNAT rules there. > > > pinging a www.dominio.tld give me "Destination Host Unreachable" > > telnet www.dominio.tld 80 result in > > telnet: connect to address 1.2.3.109: Connection refused > > > In messages I have: > > Feb 25 20:27:15 ns213325 kernel: Shorewall:dmz2fw:REJECT:IN=vmbr9 OUT= > PHYSIN=tap597i9d0 MAC=66:93:4b:b1:99:c4:00:50:56:0c:50:97:08:00 > SRC=192.168.109.9 DST=1.2.3.109 LEN=60 TOS=0x10 PREC=0x00 TTL=64 > ID=39058 DF PROTO=TCP SPT=60305 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 > Feb 25 20:27:15 ns213325 kernel: Shorewall:dmz2fw:REJECT:IN=vmbr9 OUT= > PHYSIN=tap597i9d0 MAC=66:93:4b:b1:99:c4:00:50:56:0c:50:97:08:00 > SRC=192.168.109.9 DST=1.2.3.109 LEN=60 TOS=0x10 PREC=0x00 TTL=64 > ID=45105 DF PROTO=TCP SPT=60306 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 > > > That is because you only have 1 out of the three things needed for hairpinning from dmz->dmz. You have 'routeback' but no applicable SNAT or DNAT rules. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
