Am Freitag, 18. Oktober 2019, 21:33:04 CEST schrieb Tom Eastep: > On 10/18/19 9:56 AM, Andreas Günther wrote: > > > Andreas, > > > > > > > > > > > > The dump you sent is not a bit helpful, as the configuration had > > > > > > obviously changed by the time that problems reported above were observed > > > > > > (in the dump, the loc-fw policy is ACCEPT whereas it was obviously > > > > > > REJECT when the log message above was produced). Also, no attempt to > > > > > > connect was made between the time that the firewall was started with > > > > > > that configuration and the time when the dump was taken. Does everything > > > > > > work properly when the policy is ACCEPT? > > > > > > > > > > > > -Tom > > > > > > > > Hello Tom, > > > > > > > > after our last post I changed policy like here > > > > #SOURCE DEST POLICY LOG LEVEL > > LIMIT:BURST #loc fw ACCEPT net > > all DROP info fw all > > ACCEPT info loc all > > ACCEPT info # THE FOLLOWING POLICY MUST BE LAST > > all all REJECT info > > > > But there was the policy at ACCEPT the whole time, never REJECT. Only > > the destition I have changed. And today I have the rules around port > > 5665 limited to the connection between 192.168.1.66 and 192.168.1.70 > > to keep track. I did the same with removing the ICINGA macro from the > > rules in favor of ACTION. > > > > > > > > I have just repeated the whole action after a shorewall clear && > > shorewall startmx:~ # openssl s_client -connect 192.168.1.66:5665 > > 140027152065664:error:0200206F:system library:connect:Connection > > refused:../crypto/bio/b_sock2.c:110: > > 140027152065664:error:2008A067:BIO routines:BIO_connect:connect > > error:../crypto/bio/b_sock2.c:111: connect:errno=111 > > > > and > > > > neckar:/etc/shorewall # shorewall show log | grep '192.168.1.70' Oct > > 18 18:47:17 loc-net ACCEPT IN=vmbr1 OUT=vmbr0 SRC=192.168.1.70 > > DST=5.9.124.53 LEN=192 TOS=0x00 PREC=0x00 TTL=63 ID=42263 DF PROTO=UDP > > SPT=35273 DPT=24441 LEN=172 Oct 18 18:47:20 > > Shorewall:loc-fw:REJECT:IN=vmbr1 OUT= SRC=192.168.1.70 > > DST=192.168.1.66 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8263 DF PROTO=TCP > > SPT=42332 DPT=5665 WINDOW=29200 RES=0x00 SYN URGP=0 > > > > You can see the connection is still rejected. I have generated a new dump. > > But there is no rule shown in the dump that could generate that last > message!!! > > teastep@Asus:~/.cache/.fr-C6WoE4$ fgrep REJECT shorewall_dump-2.txt > 0 0 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 0 level 6 prefix "INPUT REJECT " 0 0 LOG > all -- * * 0.0.0.0/0 0.0.0.0/0 > LOG flags 0 level 6 prefix "FORWARD REJECT " 0 0 REJECT tcp -- * > * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset > 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 > reject-with icmp-port-unreachable 0 0 REJECT icmp -- * > * 0.0.0.0/0 0.0.0.0/0 reject-with > icmp-host-unreachable 0 0 REJECT all -- * * 0.0.0.0/0 > 0.0.0.0/0 reject-with icmp-host-prohibited ipt_REJECT > 16384 8 > nf_reject_ipv4 16384 1 ipt_REJECT > Extended REJECT (ENHANCED_REJECT): Available > teastep@Asus:~/.cache/.fr-C6WoE4$ > > Note that the only two logging rules that specify REJECT are for the > INPUT and FORWARD chains. The message above is out of the 'loc-fw' chain > which contains only an ACCEPT logging rule. > > Chain loc-fw (1 references) > pkts bytes target prot opt in out source > destination 0 0 dynamic all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED 0 0 tcpflags tcp > -- * * 0.0.0.0/0 0.0.0.0/0 5 420 ACCEPT all > -- * * 0.0.0.0/0 0.0.0.0/0 ctstate > RELATED,ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 multiport dports > 22,52066,52070,52075,52076,52084 /* SSH */ 0 0 ACCEPT icmp -- * > * 0.0.0.0/0 0.0.0.0/0 icmptype 8 /* Ping */ 0 > 0 ACCEPT tcp -- * * 192.168.1.70 192.168.1.66 > tcp dpt:5665 0 0 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 0 level 6 prefix "loc-fw ACCEPT " 0 > 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 > > Note that the message you include above was generated using a different > LOGFORMAT than the one in the dump; so the configuration that produced > the dump has at least one different shorewall.conf setting than the one > that produced the log message above. Finally, notice that the dump was > apparently taken *before* the above log message was generated; from the > dump heading: > > Shorewall 5.2.3.2 Dump at neckar - Fr 18. Okt 18:47:07 CEST 2019 > ----------------------------- > > So I am at a loss to understand the results that you are seeing... > > -Tom
Hello Tom,
I see that I generated the dump at the wrong time Sorry for that.. Thus, the
whole procedure again with final dump.
mx:~ # openssl s_client -connect 192.168.1.66:5665
140544988947584:error:0200206F:system library:connect:Connection refused:../
crypto/bio/b_sock2.c:110:
140544988947584:error:2008A067:BIO routines:BIO_connect:connect error:../
crypto/bio/b_sock2.c:111:
connect:errno=111
neckar:/etc/shorewall # shorewall show log | grep '192.168.1.70'
Oct 19 10:11:50 loc-net ACCEPT IN=vmbr1 OUT=vmbr0 SRC=192.168.1.70
DST=136.243.67.138 LEN=76 TOS=0x18 PREC=0xA0 TTL=63 ID=46226 DF PROTO=UDP
SPT=123 DPT=123 LEN=56
Oct 19 10:11:52 Shorewall:loc-fw:REJECT:IN=vmbr1 OUT= SRC=192.168.1.70
DST=192.168.1.66 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5245 DF PROTO=TCP
SPT=53512 DPT=5665 WINDOW=29200 RES=0x00 SYN URGP=0
~$ fgrep REJECT shorewall_dump-4.txt
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix "INPUT REJECT "
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix "FORWARD REJECT "
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
reject-with tcp-reset
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-port-unreachable
0 0 REJECT icmp -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-unreachable
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-prohibited
Oct 19 10:11:52 Shorewall:loc-fw:REJECT:IN=vmbr1 OUT= SRC=192.168.1.70
DST=192.168.1.66 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5245 DF PROTO=TCP
SPT=53512 DPT=5665 WINDOW=29200 RES=0x00 SYN URGP=0
ipt_REJECT 16384 8
nf_reject_ipv4 16384 1 ipt_REJECT
Extended REJECT (ENHANCED_REJECT): Available
> Note that the only two logging rules that specify REJECT are for the
> INPUT and FORWARD chains. The message above is out of the 'loc-fw' chain
> which contains only an ACCEPT logging rule.
I also see that the two REJECT rules are only declared in said chains.
# shorewall show INPUT | grep LOG
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix "INPUT REJECT "
# shorewall show FORWARD | grep LOG
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix "FORWARD REJECT "
That's why I ask here my question, because I also can not explain where the
REJECT comes from in the dump, if the chain "loc-fw" only ACCEPT, not a single
REJECT contains.
> Note that the message you include above was generated using a different
> LOGFORMAT than the one in the dump; so the configuration that produced
> the dump has at least one different shorewall.conf setting than the one
> that produced the log message above.
I can now absolutely not understand why the LOGFORMAT should differ. My
settings regarding the log in shorewall.conf are the following and differ from
the default file only in "LOGLIMIT":
LOG_LEVEL="info"
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_MARTIANS=Yes
LOG_VERBOSITY=2
LOG_ZONE=Both
LOGALLNEW=
LOGFILE=/var/log/messages
LOGFORMAT="%s %s "
LOGTAGONLY=No
#LOGLIMIT="s:1/sec:10"
LOGLIMIT=
MACLIST_LOG_LEVEL="$LOG_LEVEL"
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
SFILTER_LOG_LEVEL="$LOG_LEVEL"
SMURF_LOG_LEVEL="$LOG_LEVEL"
STARTUP_LOG=/var/log/shorewall-init.log
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
UNTRACKED_LOG_LEVEL=
I think the key question is why a REJECT is generated when none is implemented
for this case in "loc-fw".
Otherwise, tell me how I have to test and log with which commands to get the
basics right.
Best regards
Andreas
shorewall_dump-4.txt.bz2
Description: application/bzip
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
