I have a server in my DMZ.
I configured it with a DNAT rule and added the IP to the
/etc/shorewall/masq so it is acccessible from the Internet and it is see
with its public IP. No problem on this.
If I try to connect to www.mydomain.com from the server itself, it
doesn''t
work.
I have IP_FORWARDING=On in shorewall.conf
Tried with shorewall 4.4.11.6 and 4.4.16.1.
The firewall box is a ProxMox VE and the server is a KVM based VM in the
same ProxMox box.
Any hints?
--
Thanks,
Paolo
____________________________________________
------------------------------------------------------------------------------
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
On 2/23/11 5:33 AM, Paolo Andretta wrote:> > I have a server in my DMZ. > I configured it with a DNAT rule and added the IP to the > /etc/shorewall/masq so it is acccessible from the Internet and it is see > with its public IP. No problem on this. > If I try to connect to www.mydomain.com from the server itself, it doesn''t > work. > I have IP_FORWARDING=On in shorewall.conf > > Tried with shorewall 4.4.11.6 and 4.4.16.1. > > The firewall box is a ProxMox VE and the server is a KVM based VM in the > same ProxMox box. > > Any hints?Put an entry for the server in its own /etc/hosts file. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Wed, 23 Feb 2011, Tom Eastep wrote:>> I have a server in my DMZ. >> I configured it with a DNAT rule and added the IP to the >> /etc/shorewall/masq so it is acccessible from the Internet and it is see >> with its public IP. No problem on this. >> If I try to connect to www.mydomain.com from the server itself, it doesn''t >> work. >> I have IP_FORWARDING=On in shorewall.conf >> >> Tried with shorewall 4.4.11.6 and 4.4.16.1. >> >> The firewall box is a ProxMox VE and the server is a KVM based VM in the >> same ProxMox box. >> >> Any hints? > > Put an entry for the server in its own /etc/hosts file.I currently put entries like: 192.168.a.b www.mydomain.com 192.168.a.b mydomain.com .... in the server''s /etc/hosts (VM), but I am searching for a better solution. Having many hosts with some VM that also have many vhosts on it the /etc/hosts solution don''t seems the better :-) -- Thanks, Paolo ____________________________________________ ------------------------------------------------------------------------------ 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
On 2/23/11 8:56 AM, Paolo Andretta wrote:> On Wed, 23 Feb 2011, Tom Eastep wrote: > >>> I have a server in my DMZ. >>> I configured it with a DNAT rule and added the IP to the >>> /etc/shorewall/masq so it is acccessible from the Internet and it is see >>> with its public IP. No problem on this. >>> If I try to connect to www.mydomain.com from the server itself, it doesn''t >>> work. >>> I have IP_FORWARDING=On in shorewall.conf >>> >>> Tried with shorewall 4.4.11.6 and 4.4.16.1. >>> >>> The firewall box is a ProxMox VE and the server is a KVM based VM in the >>> same ProxMox box. >>> >>> Any hints? >> >> Put an entry for the server in its own /etc/hosts file. > > I currently put entries like: > > 192.168.a.b www.mydomain.com > 192.168.a.b mydomain.com > .... > > in the server''s /etc/hosts (VM), but I am searching for a better > solution. > Having many hosts with some VM that also have many vhosts on it the > /etc/hosts solution don''t seems the better :-) >The available solutions in preferred order are: a) Don''t use NAT - use Proxy ARP instead. b) Use split DNS c) Use Hosts file d) Miserable kludge using Netfilter The last is horrible solution because it routes traffic from a host to itself through a second host. That is pure madness. Plus, it makes that traffic appear to come from the second host!!!!! -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 23/02/11 16:56, Paolo Andretta wrote:> On Wed, 23 Feb 2011, Tom Eastep wrote: > > >>> I have a server in my DMZ. >>> I configured it with a DNAT rule and added the IP to the >>> /etc/shorewall/masq so it is acccessible from the Internet and it is see >>> with its public IP. No problem on this. >>> If I try to connect to www.mydomain.com from the server itself, it doesn''t >>> work. >>> I have IP_FORWARDING=On in shorewall.conf >>> >>> Tried with shorewall 4.4.11.6 and 4.4.16.1. >>> >>> The firewall box is a ProxMox VE and the server is a KVM based VM in the >>> same ProxMox box. >>> >>> Any hints? >>> >> Put an entry for the server in its own /etc/hosts file. >> > I currently put entries like: > > 192.168.a.b www.mydomain.com > 192.168.a.b mydomain.com > .... > > in the server''s /etc/hosts (VM), but I am searching for a better > solution. > Having many hosts with some VM that also have many vhosts on it the > /etc/hosts solution don''t seems the better :-) > >Would something roughly as documented here: http://www.shorewall.net/FAQ.htm#faq2 help? ------------------------------------------------------------------------------ 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
On Wed, 23 Feb 2011, Tom Eastep wrote:>>>> . . .>>>> The firewall box is a ProxMox VE and the server is a KVM based VM in the >>>> same ProxMox box. >>>> >>>> Any hints? >>> >>> Put an entry for the server in its own /etc/hosts file. >> >> I currently put entries like: >> >> 192.168.a.b www.mydomain.com >> 192.168.a.b mydomain.com >> .... >> >> in the server''s /etc/hosts (VM), but I am searching for a better >> solution. >> Having many hosts with some VM that also have many vhosts on it the >> /etc/hosts solution don''t seems the better :-) >> > > The available solutions in preferred order are: > > a) Don''t use NAT - use Proxy ARP instead. > b) Use split DNS > c) Use Hosts file > d) Miserable kludge using Netfilterd) NO. I like the KISS philosofy :-) c) & b) Not applicable. Require global restructuration of our systems ... a) FWIK (I have also rapidly re-read proxy arp docs, but my understanding for this matter is not complete as your), using Proxy ARP require to use Public IP on the server. This broke many other configurations that depends on IP assigned to the box. There is a way to use Proxy ARP still having only the current Private IP on the server (not as alias ...)? In my mind I thinked my problem is only matter of some iptables option that I dont'' know because I use this configuration schema with others FW systems from many years and I haven''t this problem. I have verified it now on a system that use an physical IpCop 1.4.x fw, another that use a virtual IpCop 1.4.x fw and also a pfSense fw (not comparable because BSD/pfw based ...). Where is the trick? Thanks, Paolo ____________________________________________ ------------------------------------------------------------------------------ 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
On Wed, 23 Feb 2011, Dominic Benson wrote:>>>> I have a server in my DMZ. >>>> I configured it with a DNAT rule and added the IP to the >>>> /etc/shorewall/masq so it is acccessible from the Internet and it is see >>>> with its public IP. No problem on this. >>>> If I try to connect to www.mydomain.com from the server itself, it doesn''t >>>> work. >>>> I have IP_FORWARDING=On in shorewall.conf >>>> >>>> Tried with shorewall 4.4.11.6 and 4.4.16.1. >>>> >>>> The firewall box is a ProxMox VE and the server is a KVM based VM in the >>>> same ProxMox box. >>>> >>>> Any hints? >>>> >>> Put an entry for the server in its own /etc/hosts file. >>> >> I currently put entries like: >> >> 192.168.a.b www.mydomain.com >> 192.168.a.b mydomain.com >> .... >> >> in the server''s /etc/hosts (VM), but I am searching for a better >> solution. >> Having many hosts with some VM that also have many vhosts on it the >> /etc/hosts solution don''t seems the better :-) >> >> > 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? Regards, Paolo ____________________________________________ ------------------------------------------------------------------------------ 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
On 2/24/11 11:22 AM, Paolo Andretta 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. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 24 Feb 2011, at 19:37, Tom Eastep wrote:> On 2/24/11 11:22 AM, Paolo Andretta 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?Apologies, I realised about 5 seconds after sending the e-mail what the subject meant! Given that, it sounds to me like you want to use 2a, *not* 2b. 2b is based on there being *three* zones: WAN, LAN and DMZ, and permitting LAN -> DMZ access using public IPs. 2a is for two zones, WAN and DMZ, where you need to permit DMZ -> DMZ using public IPs. Your case sounds to me like the latter. Sorry if I have misunderstood! ------------------------------------------------------------------------------ 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
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 #/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 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 -- Thanks, Paolo ____________________________________________ APF Piazza Serenissima, 20 31033 Castelfranco V.to (TV) - (Italy) e-mail: Andretta@andretta.com web : http://www.apf.it Tel. : +39 0423 72.20.37 r.a. Fax : +39 0423 74.41.68 ____________________________________________ ------------------------------------------------------------------------------ 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
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.108Please 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.108I 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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Fri, 25 Feb 2011, Tom Eastep wrote:>>> 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.I simply ignore the warning ... :-) Ok, Changed in: vmbr0 192.168.109.0/24 1.2.3.109 vmbr0 192.168.110.0/24 1.2.3.110 vmbr0 192.168.108.0/24 1.2.3.108 vmbr9 192.168.109.0/24 1.2.3.109 <<< NEW Attempt> And I don''t see any SNAT rule for dmz->dmz traffic.I don''t understand a logic for a correct syntax Can please, give an example?>> #/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.Added: DNAT dmz dmz:192.168.109.9 tcp 20,21,80,443 - 1.2.3.109>> >> >> > > 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.Adding: vmbr9 192.168.109.0/24 1.2.3.109 to /masq and: DNAT dmz dmz:192.168.109.9 tcp 20,21,80,443 - 1.2.3.109 to /rules seems solve the problem. But I reach this result by attpmts, not following a logical path (in my mind that have limited understanding of [SD]NAT & c. Is this conf correct? Can I extend to the other servers or am I solving a problem and generating many others? Thank, Paolo ------------------------------------------------------------------------------ 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
On 2/25/11 12:18 PM, Paolo Andretta wrote:> On Fri, 25 Feb 2011, Tom Eastep wrote: >> Ok, Changed in: > > vmbr0 192.168.109.0/24 1.2.3.109 > vmbr0 192.168.110.0/24 1.2.3.110 > vmbr0 192.168.108.0/24 1.2.3.108 > > vmbr9 192.168.109.0/24 1.2.3.109 <<< NEW AttemptShould be: vmbr9:192.168.109.1 192.168.109.0/24 1.2.3.109> > DNAT dmz dmz:192.168.109.9 tcp 20,21,80,443 - 1.2.3.109Correct> > to /rules seems solve the problem. > But I reach this result by attpmts, not following a logical path (in my > mind that have limited understanding of [SD]NAT & c. > Is this conf correct? > Can I extend to the other servers or am I solving a problem and generating > many others?Yes -- you need one line per server in each file. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Fri, 25 Feb 2011, Tom Eastep wrote:>> Ok, Changed in: >> >> vmbr0 192.168.109.0/24 1.2.3.109 >> vmbr0 192.168.110.0/24 1.2.3.110 >> vmbr0 192.168.108.0/24 1.2.3.108 >> >> vmbr9 192.168.109.0/24 1.2.3.109 <<< NEW Attempt > > Should be: > > vmbr9:192.168.109.1 192.168.109.0/24 1.2.3.109That not work. Instead seems Ok if I use: vmbr9:192.168.109.97 192.168.109.0/24 1.2.3.109 Internal server''s IP is 192.168.109.97 while 192.168.109.1 is the FW IP>> to /rules seems solve the problem. >> But I reach this result by attpmts, not following a logical path (in my >> mind that have limited understanding of [SD]NAT & c. >> Is this conf correct? >> Can I extend to the other servers or am I solving a problem and generating >> many others? > > Yes -- you need one line per server in each file.At the moment I have tried only in FW where I have 1 server for every interface. Having more servers for interfaces (192.168.109.97, 192.168.109.101, 192.168.109.102, ...), is simply matter of having vmbr9:192.168.109.97 192.168.109.0/24 1.2.3.109 vmbr9:192.168.109.101 192.168.109.0/24 1.2.3.101 vmbr9:192.168.109.102 192.168.109.0/24 1.2.3.102 . . . in the /masq file? And obvioulsy the related: DNAT net dmz:192.168.109.97 tcp 20,21,80,443 - 1.2.3.109 DNAT dmz dmz:192.168.109.97 tcp 20,21,80,443 - 1.2.3.109 DNAT net dmz:192.168.109.101 tcp 20,21,80,443 - 1.2.3.101 DNAT dmz dmz:192.168.109.101 tcp 20,21,80,443 - 1.2.3.101 DNAT net dmz:192.168.109.102 tcp 20,21,80,443 - 1.2.3.102 DNAT dmz dmz:192.168.109.102 tcp 20,21,80,443 - 1.2.3.102 . . . in the /rules? Thaks, Paolo ____________________________________________ ------------------------------------------------------------------------------ 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
On 2/26/11 3:56 AM, Paolo Andretta wrote:> On Fri, 25 Feb 2011, Tom Eastep wrote: > >>> Ok, Changed in: >>> >>> vmbr0 192.168.109.0/24 1.2.3.109 >>> vmbr0 192.168.110.0/24 1.2.3.110 >>> vmbr0 192.168.108.0/24 1.2.3.108 >>> >>> vmbr9 192.168.109.0/24 1.2.3.109 <<< NEW Attempt >> >> Should be: >> >> vmbr9:192.168.109.1 192.168.109.0/24 1.2.3.109 > > That not work. > > Instead seems Ok if I use: > > vmbr9:192.168.109.97 192.168.109.0/24 1.2.3.109 > > Internal server''s IP is 192.168.109.97 while 192.168.109.1 is the FW IPIf you look back through this email thread, you will find that you have never given us these details; we have been trying to guess them based on what you have told us.> > >>> to /rules seems solve the problem. >>> But I reach this result by attpmts, not following a logical path (in my >>> mind that have limited understanding of [SD]NAT & c. >>> Is this conf correct? >>> Can I extend to the other servers or am I solving a problem and generating >>> many others? >> >> Yes -- you need one line per server in each file. > > At the moment I have tried only in FW where I have 1 server for every > interface. Having more servers for interfaces (192.168.109.97, > 192.168.109.101, 192.168.109.102, ...), is simply matter of having > > vmbr9:192.168.109.97 192.168.109.0/24 1.2.3.109 > vmbr9:192.168.109.101 192.168.109.0/24 1.2.3.101 > vmbr9:192.168.109.102 192.168.109.0/24 1.2.3.102 > . . . > > in the /masq file? > > > And obvioulsy the related: > > DNAT net dmz:192.168.109.97 tcp 20,21,80,443 - 1.2.3.109 > DNAT dmz dmz:192.168.109.97 tcp 20,21,80,443 - 1.2.3.109 > > DNAT net dmz:192.168.109.101 tcp 20,21,80,443 - 1.2.3.101 > DNAT dmz dmz:192.168.109.101 tcp 20,21,80,443 - 1.2.3.101 > > DNAT net dmz:192.168.109.102 tcp 20,21,80,443 - 1.2.3.102 > DNAT dmz dmz:192.168.109.102 tcp 20,21,80,443 - 1.2.3.102 > > . . . > > in the /rules?Yes. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Sat, 26 Feb 2011, Tom Eastep wrote:>>>> Ok, Changed in: >>>> >>>> vmbr0 192.168.109.0/24 1.2.3.109 >>>> vmbr0 192.168.110.0/24 1.2.3.110 >>>> vmbr0 192.168.108.0/24 1.2.3.108 >>>> >>>> vmbr9 192.168.109.0/24 1.2.3.109 <<< NEW Attempt >>> >>> Should be: >>> >>> vmbr9:192.168.109.1 192.168.109.0/24 1.2.3.109 >> >> That not work. >> >> Instead seems Ok if I use: >> >> vmbr9:192.168.109.97 192.168.109.0/24 1.2.3.109 >> >> Internal server''s IP is 192.168.109.97 while 192.168.109.1 is the FW IP > > If you look back through this email thread, you will find that you have > never given us these details; we have been trying to guess them based on > what you have told us.;-) Hope my limited english can be correctly understanded ;-) My comment, wasn''t a critic. I can only thanks you and other people for the work and for the support given without any compensation. I was only tryng to clarify to me the logic of the syntax. And .1 in my mind have an exact role (the GW), so this create me some doubt that I can solve only asking you and/or tryng ... :-) Thanks again for work, support and patience. -- Regards, Paolo ____________________________________________ ------------------------------------------------------------------------------ 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