On 3/13/24 18:31, Tuomo Soini wrote:
...
Note rplog here. That means rpfilter is preventing this packet. That
means you have a problem with routing.
I can't follow. How can routing be dependent on the type of ICMP6
packet? The connection works fine for "normal packets"
I did a "shorewall6 dump" and looked at the output.
The only places where rplog occurs is in the mangle table, which I did
not configure (I have no tcrules or mangle in my /etc/shorewall6), so
they must be some default setting:
Mangle Table
Chain PREROUTING (policy ACCEPT 337 packets, 59636 bytes)
pkts bytes target prot opt in out source
destination
...
0 0 rplog 0 -- ROT1 * ::/0
::/0 rpfilter validmark invert ctstate INVALID,NEW,RELATED
0 0 rplog 0 -- AMS2 * ::/0
::/0 rpfilter validmark invert ctstate INVALID,NEW,RELATED
...
Chain rplog (16 references)
pkts bytes target prot opt in out source
destination
0 0 NFLOG 0 -- * * ::/0
::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix
"Sh6:rplog:DROP:"
0 0 DROP 0 -- * * ::/0 ::/0
My suspicion was that the connection tracking somehow fails and the
incoming packet cannot be associated with a previous packet.
But wireshark can follow the entire tcp stream as coherent and also
"highlights" the ICMP6 errors (which are dropped by the PREROUTING chain).
So I'm still puzzled how to get rid of the DROP in the rplog chain and
if it would even be a good idea to do so.
And I'm still trying to find out why my setting in ulogd.conf is ignored
and logs are sent to this "other" logfile. Documentation is very sparse
on this.
Kind regards,
Uwe
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
