On Sun, Sep 6, 2015 at 8:38 PM, Tom Eastep <[email protected]> wrote:



> > I'm really enjoying Shorewall for now. It's a bit "complex" for the
> > newcomer but highly configurable, to an impressive level I must say.
> >
>
> Glad to hear that it is working for you.
>

I confirm that I'm liking Shorewall a lot! It is indeed very very flexible.
I decided to put it on a more serious setup to see it in action, so far so
good.

I'm facing a minor problem, very annoying for me but technically harmless.
The thing is I would like to understand what's going on exactly. This is
SNAT related.

I have a hosted server somewhere and here's the setup : eth0 connected to
internet with a public IP address. On this host, there are several LXC
containers, all connected to a bridge similar to the default lxcbr0 but
with another name and another IP range.

Among the LXC containers, which are all assigned to one and one service,
two of them need to get out to internet to do their stuff. One is an HTTP
proxy needing acces to world/http(s) and the other is a SMTP server needing
access to world/smtp.

"interfaces" file:
net   eth0   nets=(!10.1.1.0/24),nosmurfs,rpfilter
vdmz vbr   nets=(!10.1.1.0/24),nosmurfs,rpfilter

note: using "bridge" for "vdmz" zone does not seem to harm nor benefit in a
visible way.

"zones" file:
fw   firewall
net  ipv4
vdmz   ipv4

"policy" file:
all all DROP info

"masq" file:
# smtp
eth0   10.1.1.1   ${PUBLIC_IP}   tcp  smtp
eth0   10.1.1.2   ${PUBLIC_IP}   tcp  http,https

of course PUBLIC_IP is defined in "params"

"rules" file:

ACCEPT { source=vdmz:10.1.1.2 dest=net proto=tcp dport=http,https }
SMTP(ACCEPT) { source=vdmz:10.1.1.1 dest=net }

There are other rules above these but they are irrelevant. Disabling them
does not change anything to the annoyance.

So here is the problem : With this setup, when I'm inside the SMTP
container for example, a simple "nc some-host-on-internet 25" works but
also produces 5 DROP hits in the syslog! In fact, it produces as many hits
as LXC containers I have attached to the bridge. In this case, I have 5
other containers. Here are the logs :

Shorewall:FORWARD:DROP:IN=vbr OUT=vbr PHYSIN=veSMTP PHYSOUT=veSALT
SRC=10.1.1.1 DST=xx.xx.xx.xx PROTO=TCP SPT=30621 DPT=25 SYN URGP=0

Shorewall:FORWARD:DROP:IN=vbr OUT=vbr PHYSIN=veSMTP PHYSOUT=vePROXY
SRC=10.1.1.1 DST=xx.xx.xx.xx PROTO=TCP SPT=30621 DPT=25 SYN URGP=0

Shorewall:FORWARD:DROP:IN=vbr OUT=vbr PHYSIN=veSMTP PHYSOUT=vePHP
SRC=10.1.1.1 DST=xx.xx.xx.xx PROTO=TCP SPT=30621 DPT=25 SYN URGP=0

Shorewall:FORWARD:DROP:IN=vbr OUT=vbr PHYSIN=veSMTP PHYSOUT=veLDAP
SRC=10.1.1.1 DST=xx.xx.xx.xx PROTO=TCP SPT=30621 DPT=25 SYN URGP=0

Shorewall:FORWARD:DROP:IN=vbr OUT=vbr PHYSIN=veSMTP PHYSOUT=veIMAP
SRC=10.1.1.1 DST=xx.xx.xx.xx PROTO=TCP SPT=30621 DPT=25 SYN URGP=0

As you can see, the packet tries to get out by all "veth" interfaces. The
very same behaviour applies to the other host having external acces, the
proxy at 10.1.1.2. Any "wget http://website.tld"; or "nc website 80" does
the exact same thing.

This setup works, I mean the SMTP and PROXY get outside and reach the
destination but the syslog gets flooded with these hits everytime. How can
I get rid of these hits? What I'm not seeing here to avoid the problem?

Thanks for any clue on this matter.

-- 
ObNox
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to