I’m dropping input packets from the “good” services I use.
I tried to figure out how to make other rules to catch them with no success.
How can I accept them without accepting the nasty stuff?
23:15:10 firewall,info Input:Other input: in:ether1 out:(none), src-mac 00:0e:83:ca:d7:47, proto TCP (ACK,PSH), 129.21.160.66:443->70.80.99.44:53919, len 169
23:15:45 firewall,info Input:Other input: in:ether1 out:(none), src-mac 00:0e:83:ca:d7:47, proto TCP (ACK,PSH), 66.36.230.100:23->70.80.99.44:1032, len 76
Here are my rules
[admin@MikroTik] /ip firewall filter> print chain input
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Allow local traffic (between router applications)
chain=input action=accept src-address-type=local dst-address-type=local
1 ;;; Established Connections
chain=input action=accept connection-state=established
2 ;;; Accept related connections
chain=input action=accept connection-state=related
3 ;;; Allow PPTP
chain=input action=accept protocol=tcp dst-port=1723
4 ;;; allow PPTP and EoIP
chain=input action=accept protocol=gre
5 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid
6 ;;; BOGONS
chain=input action=jump jump-target=BOGONS
7 ;;; Port Scanners
chain=input action=jump jump-target=pscan in-interface=ether1
8 X ;;; jump to chain ICMP
chain=input action=jump jump-target=ICMP protocol=icmp
9 ;;; Allow Broadcast Traffic
chain=input action=accept dst-address-type=broadcast
10 chain=input action=accept src-address=192.168.1.0/24
11 chain=input action=accept protocol=udp
12 ;;; Log and drop everything else
chain=input action=log in-interface=ether1 log-prefix="Input:Other"
13 ;;; Log and drop everything else
chain=input action=drop in-interface=ether1
That’s one good question - looking at IPs, both used by devices sitting behind the router and NAT.
Both devices maintain (keep-alive I guess) connection to their servers out there, so the servers can contact them when necessary. One of them is SIP adapter, it maintains reservation with the server so server can send incoming calls to the NAT-ed adapter.
I don’t understand how these ended up in input chain - may be because it’s responses, TCP (ACK,PSH)?
All the rules you posted only refer to the input chain. dst-nat happens in prerouting, which is before input/forward/output. So after dstnat that stuff would be in the forward chain. Do you have any rules for the forward chain, and can you post them?
Further responses wouldn’t go into input ever if the initial handshake (or even just the SYN) got dstnat’d into something behind the router and ended up in the forward chain. NAT happens once at the beginning of the connection and then gets looked up in the state table, so all packets for the flow will be in the same chain, always.
The reason is there should not be any. A device behind NAT opens a connection to the server with main purpose to let the server contact the device without explicit “port forwarding” or dstnat rules - as long as connection is valid, server can “reply”, can’t it? It works without a glitch on any average consumer router. Why I have unaccounted response packets in Mikrotik?.. a mystery…
Here’s my forward chain:
[admin@MikroTik] > /ip firewall filter print chain forward
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Established Connections
chain=forward action=accept connection-state=established
1 ;;; Related connections
chain=forward action=accept connection-state=related
2 ;;; Drop invalid connections
chain=forward action=drop connection-state=invalid
3 ;;; BOGONS
chain=forward action=jump jump-target=BOGONS
4 ;;; Port Scanners
chain=forward action=jump jump-target=pscan in-interface=ether1
5 ;;; !!! Check for well-known viruses !!!
chain=forward action=jump jump-target=virus
6 X ;;; jump to chain ICMP
chain=forward action=jump jump-target=ICMP protocol=icmp
7 ;;; jump to chain services
chain=forward action=jump jump-target=services in-interface=!ether1
8 chain=forward action=log in-interface=ether1 log-prefix="FWD Else"
9 chain=forward action=drop in-interface=ether1