Hi Folks,
I''m new to the list, so please be kind.
Running shorewall 4.0.12.
I have a problem regarding DNATing syslog messages to an internal host. My
firewall is inside a corporate network, protecting a department network, and
i want to allow that some hosts in the company send their syslog messages to
one of our syslog servers that is protected by this firewall. My problem is
that this is working for some hosts but not all: for instance:
- I want that hosts in network 10.250.251.0/24 (outside the firewall) can
log their syslog messages to the protected host 10.200.200.130 (syslog
server) that is placed in a dmz.
- Firewall IP address is 10.79.79.1
What is happening is that it works for some hosts, e.g., 10.250.251.137, but
not for others, e.g., 10.250.251.136 here i got the following DROP (see
rules below):
Jul 21 18:26:42 fireball kernel: Shorewall:net2fw:DROP:IN=eth1
OUTMAC=00:02:a5:60:c8:0c:00:15:fa:d7:89:20:08:00 SRC=10.250.251.136
DST10.79.79.1 LEN=200 TOS=0x00 PREC=0x00 TTL=254 ID=5422 PROTO=UDP SPT=514
DPT=514 LEN=180
I have the following relevant config (some entries removed for
clarification):
/etc/shorewall/zones:
fw firewall
lan ipv4 # downstream 2nd-level firewall
net ipv4 # corporate network
dmz0 ipv4 # dmz0 - frontend service DMZ
/etc/shorewall/interfaces:
lan eth0 detect
net eth1 detect tcpflags,routefilter,nosmurfs,logmartians
dmz0 eth3 detect
/etc/shorewall/policy:
fw all DROP info
net all DROP info
dmz0 all DROP info
lan all DROP info
all all REJECT info
/etc/shorewall/masq:
eth1 eth0
eth1 eth3
/etc/shorewall/rules (relevant entries only):
Syslog/DNAT net:10.250.251.133 dmz0:10.200.200.130
Syslog/DNAT net:10.250.251.134 dmz0:10.200.200.130
Syslog/DNAT net:10.250.251.135 dmz0:10.200.200.130
Syslog/DNAT net:10.250.251.136 dmz0:10.200.200.130
Syslog/DNAT net:10.250.251.137 dmz0:10.200.200.130
Syslog/DNAT net:10.250.251.181 dmz0:10.200.200.130
Syslog/DNAT net:10.250.251.180 dmz0:10.200.200.130
My nat counters show that:
# shorewall show nat
[...]
Chain net_dnat (1 references)
pkts bytes target prot opt in out source
destination
0 0 DNAT udp -- * * 10.250.251.133
0.0.0.0/0 udp dpt:514 to:10.200.200.130
0 0 DNAT udp -- * * 10.250.251.134
0.0.0.0/0 udp dpt:514 to:10.200.200.130
0 0 DNAT udp -- * * 10.250.251.135
0.0.0.0/0 udp dpt:514 to:10.200.200.130
0 0 DNAT udp -- * * 10.250.251.136
0.0.0.0/0 udp dpt:514 to:10.200.200.130
3 445 DNAT udp -- * * 10.250.251.137
0.0.0.0/0 udp dpt:514 to:10.200.200.130
0 0 DNAT udp -- * * 10.250.251.181
0.0.0.0/0 udp dpt:514 to:10.200.200.130
0 0 DNAT udp -- * * 10.250.251.180
0.0.0.0/0 udp dpt:514 to:10.200.200.130
Any ideas?
Thanks,
Tunga
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tunga Tungstein wrote:> I have the following relevant config (some entries removed for > clarification):As we state clearly at http://www.shorewall.net/support.htm, we really don''t want to see your configuration files unless we ask for them. The reasons are: a) What you think is relevant is likely not where the problem is (if it was, you would have already found the problem, right?). b) In the final analysis, what is in your config files is immaterial -- it is what is in your kernel''s running configuration that determines what happens.> > Syslog/DNAT net:10.250.251.133 <http://10.250.251.133> > dmz0:10.200.200.130 <http://10.200.200.130>Whatever email client you use should be banned unconditionally from the internet. The way that it modifies what you post is criminal. If there is any way to disable that broken behavior, please do so.> > Chain net_dnat (1 references) > pkts bytes target prot opt in out source > destination > 0 0 DNAT udp -- * * 10.250.251.133 > <http://10.250.251.133> 0.0.0.0/0 <http://0.0.0.0/0> udp > dpt:514 to:10.200.200.130 <http://10.200.200.130>More mangled text....> > Any ideas? >Yes -- please resubmit your problem report providing the information described at http://www.shorewall.net/support.htm#Guidelines. I''ll be happy to try to determine what the problem is. -Tom PS -- the information will also let me know if you use Shorewall-shell or Shorewall-perl. Shorewall-shell is susceptible to packets creating bogus connection tracking entries during start/restart which can lead to errors of this sort. -- 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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> > Yes -- please resubmit your problem report providing the information > described at http://www.shorewall.net/support.htm#Guidelines. I''ll be > happy to try to determine what the problem isThe problem turned out to be stale conntrack entries. Once they were deleted using the ''conntrack'' tool, the firewall worked as expected. -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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/