Hello, In iptables one could have this: ... *nat ... :POSTROUTING ACCEPT [0:0] ... -A POSTROUTING -i eth1 -o eth0 -s 10.10.10.0/24 -d 192.168.1.0/24 -j ACCEPT -A POSTROUTING -o eth0 -j MASQUERADE ... This allows for some specific traffic (from network 10.10.10.0/24 to network 192.168.1.0/24 ) to not be masquerade, or source nated and just be simply routed. I can''t find a way to do this with shorewall. I want all the traffic going out to be source nated except in that specific case. I might, use the start script for this, by adding the rule after the shorewall gets started, although it does not seems the right way. I could have overlooked the documentation, but I didn''t find this specific case covered in any of the documentation pages. Thanks for all your help. -- Duarte Rocha <dfr@eurotux.com> Eurotux Informática, S.A. [http://eurotux.com] _____________________________________________________ A)bort, R)etry, I)nfluence with large hammer. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 08/17/2012 09:41 AM, Duarte Fernandes Rocha wrote:> Hello, > > In iptables one could have this: > > ... > > *nat > > ... > > :POSTROUTING ACCEPT [0:0] > > ... > > -A POSTROUTING -i eth1 -o eth0 -s 10.10.10.0/24 -d 192.168.1.0/24 -j ACCEPT > > -A POSTROUTING -o eth0 -j MASQUERADE > > ... > > This allows for some specific traffic (from network 10.10.10.0/24 to > network 192.168.1.0/24 ) to not be masquerade, or source nated and just > be simply routed. > > I can''t find a way to do this with shorewall. I want all the traffic > going out to be source nated except in that specific case. > > I might, use the start script for this, by adding the rule after the > shorewall gets started, although it does not seems the right way. > > I could have overlooked the documentation, but I didn''t find this > specific case covered in any of the documentation pages. > > Thanks for all your help.You cannot use ''-i eth1'' in the POSTROUTING chain. root@gateway:~# iptables -A POSTROUTING -i eth1 -o eth0 -s \ 10.10.10.0/24 -d 192.168.1.0/24 -j ACCEPT iptables v1.4.15: Can''t use -i with POSTROUTING Try `iptables -h'' or ''iptables --help'' for more information. root@gateway:~# Assuming that only 10.10.10.0/24 connections through eth1, you can eth0:!192.168.1.0/24 10.10.10.0/24 -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Duarte Fernandes Rocha
2012-Aug-17 18:44 UTC
Re: Adding postrouting ACCEPT rule to nat table
Hi Tom, Thanks for the reply. Indeed the rule does not work, but you did get what I meant :) Your sugestion is not really waht I''m looking for. Altough I could do it that way, I would prefer to have a way put a rule on the POSTROUTING table, or in this case de eth0_masq CHAIN to ACCEPT some specific traffic, jumping over the masquerade. like : /etc/shorewall/masq eth0 10.1.6.0/24,10.0.0.0/24,10.0.6.0/23,10.1.1.0/24,10.5.0.0/24 and generate this: eth0_masq - [0:0] -A POSTROUTING -o eth0 -j eth0_masq -A eth0_masq -s 10.1.6.0/24 -d 192.168.1.0/24 -j ACCEPT <- this is the rule I don''t know how to create in the shorewall -A eth0_masq -s 10.1.6.0/24 -j MASQUERADE -A eth0_masq -s 10.0.0.0/24 -j MASQUERADE -A eth0_masq -s 10.0.6.0/23 -j MASQUERADE -A eth0_masq -s 10.1.1.0/24 -j MASQUERADE -A eth0_masq -s 10.5.0.0/24 -j MASQUERADE regards, Duarte Rocha ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/17/12 11:44 AM, Duarte Fernandes Rocha wrote:> Hi Tom, > > > > Thanks for the reply. > > > > Indeed the rule does not work, but you did get what I meant :) > > > > Your sugestion is not really waht I''m looking for. Altough I could do it > that way, I would prefer to have a way put a rule on the POSTROUTING > table, or in this case de eth0_masq CHAIN to ACCEPT some specific > traffic, jumping over the masquerade. like :Well, what I suggested is all that is currently available. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/20/12 5:39 PM, Tom Eastep wrote:> > Well, what I suggested is all that is currently available. >That having been said, the attached patch should allow you to place CONTINUE in the ADDRESSES columm to generate an ACCEPT rule. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/20/12 6:02 PM, Tom Eastep wrote:> On 8/20/12 5:39 PM, Tom Eastep wrote: > >> >> Well, what I suggested is all that is currently available. >> > > That having been said, the attached patch should allow you to place > CONTINUE in the ADDRESSES columm to generate an ACCEPT rule.As I was documenting this change, I found that the existing ''NONAT'' keyword in the ACCESS column already does what you want. Sorry for the noise tonight. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Duarte Fernandes Rocha
2012-Aug-21 09:08 UTC
Re: Adding postrouting ACCEPT rule to nat table
On Monday 20 August 2012 18:14:05 Tom Eastep wrote:> On 8/20/12 6:02 PM, Tom Eastep wrote: > > On 8/20/12 5:39 PM, Tom Eastep wrote: > >> Well, what I suggested is all that is currently available. > > > > That having been said, the attached patch should allow you to place > > CONTINUE in the ADDRESSES columm to generate an ACCEPT rule. > > As I was documenting this change, I found that the existing ''NONAT'' > keyword in the ACCESS column already does what you want. > > Sorry for the noise tonight. > > -TomThe NONAT is just what I was looking for. now I have this: /etc/shorewall/masq eth0:192.168.1.0/24 10.1.6.0/24,10.0.0.0/24,10.0.6.0/23,10.1.1.0/24,10.5.0.0/24 NONAT eth0 eth1 which results in : -A eth0_masq -s 10.1.6.0/24 -d 192.168.1.0/24 -j RETURN -A eth0_masq -s 10.5.6.0/24 -d 192.168.1.0/24 -j RETURN -A eth0_masq -s 10.10.126.0/24 -d 192.168.1.0/24 -j RETURN -A eth0_masq -s 10.10.206.0/24 -d 192.168.1.0/24 -j RETURN -A eth0_masq -s 10.1.6.0/24 -j MASQUERADE -A eth0_masq -s 10.5.6.0/24 -j MASQUERADE -A eth0_masq -s 10.10.126.0/24 -j MASQUERADE -A eth0_masq -s 10.10.206.0/24 -j MASQUERADE previously I had it like this: /etc/shorewall/masq eth0:!192.168.1.0/24 10.1.6.0/24,10.5.6.0/24,10.10.126.0/24,10.10.206.0/24 which resulted in: -A eth0_masq -s 10.1.6.0/24 ! -d 192.168.1.0/24 -j MASQUERADE -A eth0_masq -s 10.5.6.0/24 ! -d 192.168.1.0/24 -j MASQUERADE -A eth0_masq -s 10.10.126.0/24 ! -d 192.168.1.0/24 -j MASQUERADE -A eth0_masq -s 10.10.206.0/24 ! -d 192.168.1.0/24 -j MASQUERADE It worked for me, but with NONAT is easier to add exceptions. regards, ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/