Shorewall users - Oct 2004 - No entries in the syslog, even though the LOG chains show counts

I have obviously done something on my system to cause it to no longer
show Shorewall log entries in the syslogs, but for the life of me I
can''t figure out what.  Let me first give you some details about my
config which will hopefully show why I think logging should be working,
and perhaps you can tell me why it''s not. 

I am using version 2.0.9 from the debian sarge package 2.0.9-1.  This is
a hosted server that is directly connected to the internet, with only
two very simple zones: fw and net.  The server is basically a standalone
machine on the internet, and its firewall is for its own services only.

My shorewall.conf, without comments, is as follows:

$ egrep -v ''^( *#)|^$'' shorewall.conf 
LOGFILE=/var/log/messages
LOGFORMAT="Shorewall:%s:%s:"
LOGLIMIT=""
LOGBURST=""
BLACKLIST_LOGLEVEL=info
LOGNEWNOTSYN=info
MACLIST_LOG_LEVEL=info
TCP_FLAGS_LOG_LEVEL=info
RFC1918_LOG_LEVEL=info
SMURF_LOG_LEVEL=info
BOGON_LOG_LEVEL=info
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=""
STATEDIR=/var/lib/shorewall
MODULESDIRCONFIG_PATH=/etc/shorewall:/usr/share/shorewall
RESTOREFILEFW=fw
IP_FORWARDING=Keep
ADD_IP_ALIASES=Yes
ADD_SNAT_ALIASES=No
TC_ENABLED=No
CLEAR_TC=Yes
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=No
ROUTE_FILTER=Yes
DETECT_DNAT_IPADDRS=No
MUTEX_TIMEOUT=60
NEWNOTSYN=No
ADMINISABSENTMINDED=Yes
BLACKLISTNEWONLY=Yes
MODULE_SUFFIXDISABLE_IPV6=No
BRIDGING=No
DYNAMIC_ZONES=No
PKTTYPE=Yes
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP

As you can see I have "info" set for most logging levels.  My
/etc/syslog.conf contains  the following lines (among others of course):

*.*;auth,authpriv.none          /var/log/syslog
kern.*                          /var/log/kern.log
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          /var/log/messages

Based on my understanding of syslog, that means that all log entries of
"kern.info" (which is what I expect iptables to be generating) should
end up in each of those three  files.  However, I get nothing.  I''ll
continue with my system config info.  Let me take a spefic example of an
event that should be generating logs but is not: the default net2all
policy.  The following is my policy file, minus comments:

$ egrep -v ''^( *#)|^$'' policy          
fw              net             ACCEPT
net             all             DROP            info
all             all             REJECT          info 

Based on the above, I expect to get Shorewall log entries via iptables
for packets that match "net2all", i.e. packets to a port that has not
been opened or allowed explicitly in my ''rules'' file.  To test
this
theory, I reset the
counters, did "shorewall show", tried to telnet to such a port from a
remote machine, and then did "shorewall show".  I did a diff on the
before and after of the two commands, and I see the counters for the
"LOG" target have increased, just as I expected:

 Chain net2all (1 references)
  pkts bytes target     prot opt in     out     source              
destination         
     0     0 ACCEPT     all  --  *      *       0.0.0.0/0           
0.0.0.0/0           state RELATED,ESTABLISHED 
     0     0 newnotsyn  tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           state NEW tcp flags:!0x16/0x02 
-    7  1188 Drop       all  --  *      *       0.0.0.0/0           
0.0.0.0/0           
-    0     0 LOG        all  --  *      *       0.0.0.0/0           
0.0.0.0/0           LOG flags 0 level 6 prefix
`Shorewall:net2all:DROP:''
-    0     0 DROP       all  --  *      *       0.0.0.0/0           
0.0.0.0/0           
+   11  1428 Drop       all  --  *      *       0.0.0.0/0           
0.0.0.0/0           
+    4   240 LOG        all  --  *      *       0.0.0.0/0           
0.0.0.0/0           LOG flags 0 level 6 prefix
`Shorewall:net2all:DROP:''
+    4   240 DROP       all  --  *      *       0.0.0.0/0           
0.0.0.0/0           

Those lines are probably folded and appear hard to read.  Basically, I
can see that between the two "shorewall show" commands, the counters
of
the last two rules, LOG and DROP, have both increased from 0 to 4,
corresponding to the connection attempt I made to a random non-opened
port.  However I still have nothing from iptables in any of the above
three syslogs for the event.  In fact there are no shorewall log events
whatsoever in any of my logs, aside from the "Shorewall Started",
"Restarted", etc.  There are no entries from iptables anywhere.

Summary:

Everything that indicates that I should be seeing iptables syslog
entries:
- shorewall.conf calls for "info" level logging for most everything
- syslog.conf defines three places for "kern.info" to go
- default policy for net2all has the "info" logging level
- counters on the LOG rule in net2all chain show that it''s being
incremented, but still no log entries

What else exists on my system that could cause iptables to not log
anything to syslog?  I have restarted both syslogd and shorewall, in
case there was stale config files, but it does not affect the problem. 
Is there any kind of sysctl or something that would cause iptables to
discard its log entries?

Thanks

The following items were requested on the problem reporting page, so I
will include them, even though I don''t think they''re relevent:

$ ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
2: teql0: <NOARP> mtu 1500 qdisc noop qlen 100
    link/void 
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop 
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP> mtu 1500 qdisc
pfifo_fast qlen 1000
    link/ether 00:ba:ac:8a:bf:ca brd ff:ff:ff:ff:ff:ff
    inet 66.17.244.20/24 brd 66.255.255.255 scope global eth0
    inet 66.17.244.21/24 brd 66.255.255.255 scope global secondary
eth0:1
    inet6 fe80::2ba:acff:fe8a:bfca/64 scope link 
5: tunl0@NONE: <NOARP> mtu 1480 qdisc noop 
    link/ipip 0.0.0.0 brd 0.0.0.0
6: gre0@NONE: <NOARP> mtu 1476 qdisc noop 
    link/gre 0.0.0.0 brd 0.0.0.0
7: ipsec0: <NOARP> mtu 0 qdisc noop qlen 10
    link/void 
8: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10
    link/void 
9: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10
    link/void 
10: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10
    link/void 
11: sit0@NONE: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0

$ ip route show
66.17.244.0/24 dev eth0  proto kernel  scope link  src 66.17.244.20 
default via 66.17.244.1 dev eth0

On Thursday 28 October 2004 23:19, Brian Dessent wrote:
> I have obviously done something on my system to cause it to no longer
> show Shorewall log entries in the syslogs, but for the life of me I
> can''t figure out what.  Let me first give you some details about
my
> config which will hopefully show why I think logging should be working,
> and perhaps you can tell me why it''s not.
>
> I am using version 2.0.9 from the debian sarge package 2.0.9-1.  This is
> a hosted server that is directly connected to the internet, with only
> two very simple zones: fw and net.  The server is basically a standalone
> machine on the internet, and its firewall is for its own services only.
>
You can quickly determine if the messages are being generated by running:

	dmesg | less

If you see ''Shorewall'' messages, then the problem is in
klogd/syslogd (have
you tried restarting klogd; I don''t recall if it is a separate service
under
Debian)?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://www.shorewall.net
Washington USA  \ teastep@shorewall.net

<broken debian logging....>
>>I have obviously done something on my system to cause it to no longer
>>show Shorewall log entries in the syslogs, but for the life of me I
>>can''t figure out what.  Let me first give you some details
about my
>>config which will hopefully show why I think logging should be working,
>>and perhaps you can tell me why it''s not.
>>
>>I am using version 2.0.9 from the debian sarge package 2.0.9-1.  This is
>>a hosted server that is directly connected to the internet, with only
>>two very simple zones: fw and net.  The server is basically a standalone
>>machine on the internet, and its firewall is for its own services only.
>>
>>    
>>
I have this same problem on one of my boxes. My guess is that it 
happened on an upgrade. I have not tried to diagnose it, I have been 
meaning to learn about how logging works in full. I am running debian, 
my logging used to work, and now it doesnt. dmesg shows the shorewall 
logs. /var/log/messages does not anymore. I think that other stuff that 
should be logged is not making it either.

I have no idea, I will have to do some research, but if you come on 
anything or anyone else has a hint, please let me know!

Thanks,
Alex Martin
http://www.rettc.com

Tom Eastep wrote:
> You can quickly determine if the messages are being generated by running:
> 
>         dmesg | less
> 
> If you see ''Shorewall'' messages, then the problem is in
klogd/syslogd (have
> you tried restarting klogd; I don''t recall if it is a separate
service under
> Debian)?
Aha.  I didn''t know klogd was a seperate daemon.  It was not running,
it
must have been killed at some point and never restarted.  When I
restarted it the last batch of kernel logs were read and added to the
syslog, just as expected.  Seems so obvious now in hindsight.  I suppose
a reboot would have fixed this as well since the initscripts would have
started it, but for stupid reasons ("uptime vanity" you might say) I
had
not tried that yet.

Thanks,
Brian

Hi,

My ISP is COMCAST and for some reason I can ping a couple of private IP, 
such as 10.67.52.34. This IP is also a private IP of one of the servers in 
my office and when I connect to my office via CISCO VPN, I cannot connect to 
the server I want.

Is there anyway I can get rid of the unwanted private IP from COMCAST?

Thank you.

Since the IP address you want to reach belongs to a network of
so-called private (also known as non-routable or RFC 1918) IP
addresses, it sits behind a router with a "public" or routable IP
address.  There are a variety of ways to accomplish your goal,
assuming you have a administrative rights on the internet-facing
router, you can set up a NAT rule to handle the connections. 
Alternatively, you can engineer a VPN tunnel between your home machine
and the machine in question.  Each solution has its own risks and
benefits.


On Sat, 30 Oct 2004 00:37:53 -0400, M Lu <mlu919@hotmail.com>
wrote:
> Hi,
> 
> My ISP is COMCAST and for some reason I can ping a couple of private IP,
> such as 10.67.52.34. This IP is also a private IP of one of the servers in
> my office and when I connect to my office via CISCO VPN, I cannot connect
to
> the server I want.
> 
> Is there anyway I can get rid of the unwanted private IP from COMCAST?
> 
> Thank you.
> 
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm
>

Hi Gary,

I have full control on the linux router (with shorewall running), but I
cannot change anything on the COMCAST modem eventhough I can http to it
(192.168.1.100).

If there is no such conflict with COMCAST private IP and my office private
IP, I would already access my office private IP via VPN (I can access other
private subnets fine), so I do not understand "engineer a VPN tunnel
between
your home machine and the machine in question".

Can you give a little bit more info on the NAT rule and the benefits and
risks between NAT and VPN. By the way, by VPN here I mean a CISCO VPN client
on my Windows machine behind the linux router to connect to my office.

Thank you




----- Original Message ----- 
From: "Gary Buckmaster" <inherently.evil@gmail.com>
To: "Mailing List for Shorewall Users"
<shorewall-users@lists.shorewall.net>
Sent: Saturday, October 30, 2004 1:30 AM
Subject: Re: [Shorewall-users] How to reach a private IP...

> Since the IP address you want to reach belongs to a network of
> so-called private (also known as non-routable or RFC 1918) IP
> addresses, it sits behind a router with a "public" or routable IP
> address.  There are a variety of ways to accomplish your goal,
> assuming you have a administrative rights on the internet-facing
> router, you can set up a NAT rule to handle the connections.
> Alternatively, you can engineer a VPN tunnel between your home machine
> and the machine in question.  Each solution has its own risks and
> benefits.
>
>
> On Sat, 30 Oct 2004 00:37:53 -0400, M Lu <mlu919@hotmail.com> wrote:
> > Hi,
> >
> > My ISP is COMCAST and for some reason I can ping a couple of private
IP,
> > such as 10.67.52.34. This IP is also a private IP of one of the
servers
in
> > my office and when I connect to my office via CISCO VPN, I cannot
connect to
> > the server I want.
> >
> > Is there anyway I can get rid of the unwanted private IP from COMCAST?
> >
> > Thank you.
> >
> > _______________________________________________
> > Shorewall-users mailing list
> > Post: Shorewall-users@lists.shorewall.net
> > Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users
> > Support: http://www.shorewall.net/support.htm
> > FAQ: http://www.shorewall.net/FAQ.htm
> >
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

M Lu wrote:
> Hi,
>
> My ISP is COMCAST and for some reason I can ping a couple of private IP,
> such as 10.67.52.34. This IP is also a private IP of one of the servers
> in my office and when I connect to my office via CISCO VPN, I cannot
> connect to the server I want.
>
> Is there anyway I can get rid of the unwanted private IP from COMCAST?
>
I don''t understand what this problem can possibly be about. When you
establish a VPN, you also set up routing for those addresses that are to
be accessed through the VPN (or if you are using Kernel 2.6 IPSEC, you
set up SPD entries for those hosts). Any systems along your default
route with IP addresses that duplicate those in the remote intranet are
irrelevant unless your default gateway is one of those systems.

The usual problem in these cases is that you need to access your ISP''s
system(s) (for example, it is you DNS server) -- there should never be a
problem where the ISP system preempts access to the remote intranet.

- -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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFBhDlkO/MAbZfjDLIRAj+nAJYvgQjsbvnoUvYGX3DyTa5lggp0AJ9txtuF
2c7W1u0HqFk5CuWsAbbsGQ==PXHN
-----END PGP SIGNATURE-----

You can quickly determine if the messages are being generated by running:
>>        dmesg | less
>>
>>If you see ''Shorewall'' messages, then the problem is
in klogd/syslogd (have
>>you tried restarting klogd; I don''t recall if it is a separate
service under
>>Debian)?
>>    
>>
>
>  
>
Thanks Tom, for your genius suggestion "restart klogd sysklogd". Now
my
shorewall is logging to the proper place. Of course this is not a 
shorewall problem... (I swear I have tried that)