ABSOLUTELY BRILLIANT JIM !
That is sooo helpful. Great pics and as they say “…they speak a 1000 words”.
Yes, I was wondering whether I could do this and now I know how thanks to you… So, I put a log in the PREROUTING chain of the mangle table. And , voila …
Mar 31 09:44:11 pi kernel: [74719.469250] IN=eth0 OUT= MAC=**** SRC=THE.PUBLIC.IP.NEEDED DST=192.168.1.10 LEN=124 TOS=0x00 PREC=0x00 TTL=55 ID=25539 PROTO=UDP SPT=51820 DPT=42612 LEN=104
and there it is. Incoming on eth0 before being forwarded to the VPN interface wg0
So I did a quick test and inserted a LOG rule on the PREROUTING chain of the mangle iptable. Voila, the public IP is in SRC for the packet. Great. So this is where I need to insert the blocking rule. This is fairly trivial and to answer your question , YES, it is possible to configure fail2ban to cover this instance by modifying fail2ban’s commands:
-
fwstart command that sets up iptables and injects a new chain f2b-ha into the filter table, and sets up the input chain that forces all incoming traffic to jump to the f2b-ha chain.
-
fwend command that removes the work done by fwend to “restore” iptables.
-
fwban command that inserts a REJECT rule into the f2b-ha chain to block <HOST>.
- and fwunban command that removes <HOST> from the f2b-ha chain.
So all that one needs to do is tweak these command definitions. I’ll post the solution on this thread shortly.
Excellent Jim. Thanks a bunch.
One more thing you may know Jim, fail2ban grabs the IP from the HA log file using the placeholder in the regexp from /etc/fail2ban/filter.d/ha.conf. So HA has already inserted the IP into the log file , but how does HA get that [correct] IP - because whether HA is running in a VPN or not, that IP is always correct - and the one I need to use - so just wondering how it acquires the IP?
Daz
EDIT
ok, this is weired and I dont know whats happening.
I set up iptables on the mangle table:-
root@pi:/etc/fail2ban# iptables -vnL -t mangle
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1269 144K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix "** prerouting **: "
2404 128K f2b-ha tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
108K 29M CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0 /* wg-quick(8) rule for wg0 */ CONNMARK restore
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
29883 13M CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xca6c /* wg-quick(8) rule for wg0 */ CONNMARK save
Chain f2b-ha (1 references)
pkts bytes target prot opt in out source destination
1065 55816 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix "** f2b **: "
0 0 DROP all -- * * aa.bb.cc.dd 0.0.0.0/0
2404 128K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
root@pi:/etc/fail2ban#
Fail2ban is correctly inserting a block [DROP] rule on public IP aa.bb.cc.dd.- CORRECT
When packets come into the PREROUTING chain, the LOG correctly identifies SRC as the public IP aa.bb.cc.dd - CORRECT
It then jumps to the f2b-ha chain - CORRECT
The LOG then writes a log but now the SRC has changed to 192.168.1.127 - INCORRECT.
So something is happening to SRC within the jump from PREROUTING to f2b chains. - INCORRECT??
192.168.1.127 is my laptop on my LAN that I am connecting to www.some.site which is then forwarding traffic to my reverse proxy server which is then redirecting traffic through my VPN - CORRECT behaviour
But why is SRC changing during the jump from PREROUTING to f2b-ha chains in mangle table. Otherwise it would be fine if SRC was not modified. I bet this is to do with S/NAT but I dont know enough about networking. At least I’m 50% there in that the SRC in PREROUTING is now as I expect. However, f2b-ha chain is not blocking the IP because SRC has now changed to 192.168.1.127.
??
