IPSec and ConnTrack

zett93 · December 7, 2020, 3:40pm

Hi,

i have a stupid issue with my MT HEX gr3.

I have IPSec tunnel between MT and FortiGate. Tunnel works fine (peer is active, all policies are estabilished), but there is no traffic through that.

I have some rules in Firewall/NAT/RAW, see below.

/ip firewall filter

21    ;;; FROM L2TP Clients
      chain=forward action=accept dst-address-list=My_VPN_ADDRESS_LIST 
      in-interface-list=My_L2TP_INTERFACES log=no log-prefix="SSA" 

22    ;;; From LOCAL LAN
      chain=forward action=accept src-address-list=VPN_ACCESS_LIST 
      dst-address-list=My_VPN_ADDRESS_LIST log=no log-prefix="" 

23    ;;; Drop unauthorized
      chain=forward action=reject reject-with=icmp-network-unreachable 
      dst-address-list=My_VPN_ADDRESS_LIST log=no log-prefix=""
      
/ip firewall nat

 0    ;;; Accept traffic to tunnel tunnel
      chain=srcnat action=accept src-address-list=Local_LAN_Networks 
      dst-address-list=My_VPN_ADDRESS_LIST

 1    ;;; Accept traffic from Atman tunnel
      chain=srcnat action=accept src-address-list=My_VPN_ADDRESS_LIST 
      dst-address-list=Local_LAN_Networks
      
/ip firewall raw

 1    ;;; Bypass IPSec traffic to Remote 
      chain=prerouting action=notrack 
      src-address-list=Local_LAN_Networks dst-address-list=My_VPN_ADDRESS_LIST

 2    ;;; Bypass IPSec traffic from Remote
      chain=prerouting action=notrack 
      src-address-list=My_VPN_ADDRESS_LISTdst-address-list=Local_LAN_Networks

BUT! When i change Connection Tracking to off, traffic will go through Tunnel without any problem.
Any idea why that isn’t working properly?

sindy · December 7, 2020, 4:03pm

None of the rules you’ve posted refers to connection-state. So it is not possible to find out what is wrong. Post the complete export of the firewall (including the address lists) and indicate the subnets at local and fortigate side which should be able to talk to each other.

Check my automatic signature below regarding anonymisation.

zett93 · December 7, 2020, 4:38pm

Okay, below You have full dump from my FW (without dst-nat port forwardings), My remote network behind Forti address is 192.168.10.0/24 and I need traffic from 192.168.20.0/24 and 192.168.30.0/24 (I have that policies in IPSec tab)

# dec/07/2020 17:17:05 by RouterOS 6.47.8
#
# model = RB750Gr3
/ip firewall address-list add address=192.168.30.0/24 list=VPN-LOCAL
/ip firewall address-list add address=216.218.206.0/24 comment="VPN Shadowserver spam" list=BLACKLIST
/ip firewall address-list add address=192.168.20.0/24 comment="Local Address" list=WHITELIST
/ip firewall address-list add address=192.168.40.0/24 list="VLAN NETWORKS"
/ip firewall address-list add address=192.168.50.0/24 list="VLAN NETWORKS"
/ip firewall address-list add address=192.168.20.0/24 list="LAN NETWORKS"
/ip firewall address-list add address=192.168.30.0/24 list="LAN NETWORKS"
/ip firewall address-list add address=my.remote.network.address comment="SSW - D1" list=MYREMOTEDCADDR
/ip firewall address-list add address=my.remote.network2.addrtess comment="SSW - D2" list=MYREMOTEDCADDR
/ip firewall address-list add address=192.168.10.0/24 comment="SSW - L1" list=SSVPN1LAN
/ip firewall address-list add address=192.168.100.0/24 comment="SSW - L2" list=SSVPN2LAN
/ip firewall address-list add address=192.168.20.18 list=REMVPN2
/ip firewall address-list add address=192.168.20.10 list=REMVPN2
/ip firewall address-list add address=192.168.20.34 list=REMVPN2
/ip firewall address-list add address=192.168.20.50 list=REMVPN2
/ip firewall address-list add address=192.168.20.12 list=REMVPN2
/ip firewall address-list add address=192.168.20.10 list=SSVPN_ACCESS
/ip firewall address-list add address=192.168.20.18 list=SSVPN_ACCESS
/ip firewall address-list add address=192.168.20.34 list=SSVPN_ACCESS
/ip firewall address-list add address=192.168.20.12 list=SSVPN_ACCESS
/ip firewall address-list add address=192.168.20.50 list=SSVPN_ACCESS
/ip firewall address-list add address=192.168.20.254 list=SSVPN_ACCESS

/ip firewall connection tracking set tcp-established-timeout=5m

/ip firewall filter add action=add-src-to-address-list address-list=BLACKLIST address-list-timeout=1h chain=input comment="Port Scanner Detect IP add to blacklist" protocol=tcp psd=21,3s,3,1 src-address-list=!WHITELIST
/ip firewall filter add action=add-src-to-address-list address-list=CHECKLIST address-list-timeout=1w chain=input comment="Port Scanner Detect IP add to checklist" protocol=tcp psd=21,3s,3,1
/ip firewall filter add action=add-src-to-address-list address-list=BLACKLIST address-list-timeout=1h chain=input comment="Syn Flood DOS attack IP add  to blacklist" connection-limit=30,32 protocol=tcp src-address-list=!WHITELIST tcp-flags=syn
/ip firewall filter add action=accept chain=input protocol=ipsec-esp
/ip firewall filter add action=accept chain=input protocol=ipsec-ah
/ip firewall filter add action=accept chain=input dst-port=161,162 protocol=udp src-address=my.remote.network.address
/ip firewall filter add action=accept chain=input comment="WINBOX ACCESS FROM VPN" dst-port=8291,80,443,20022 protocol=tcp src-address-list=VPN-LOCAL
/ip firewall filter add action=accept chain=input comment="IPSec UDP Ports" dst-port=500,4500 protocol=udp
/ip firewall filter add action=accept chain=input comment="IPSec TCP Ports" dst-port=500,4500 protocol=tcp
/ip firewall filter add action=accept chain=input comment="L2TP UDP Ports" dst-port=1701 protocol=udp
/ip firewall filter add action=accept chain=input comment="accept ICMP - only 192.168.30.x" protocol=icmp src-address=192.168.30.0/24
/ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
/ip firewall filter add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid log-prefix=INV
/ip firewall filter add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log-prefix=IN

/ip firewall filter add action=accept chain=forward dst-address-list=SSVPN1LAN in-interface-list=SS_L2TP_INTERFACE_ACCESS log-prefix=SSA
/ip firewall filter add action=accept chain=forward disabled=yes dst-address-list=SSVPN1LAN src-address-list=SSVPN_ACCESS
/ip firewall filter add action=reject chain=forward dst-address-list=SSVPN1LAN reject-with=icmp-network-unreachable

/ip firewall filter add action=accept chain=forward connection-state="" dst-address-list=SSVPN2LAN in-interface-list=SS_L2TP_INTERFACE_ACCESS log-prefix=SSA
/ip firewall filter add action=accept chain=forward disabled=yes dst-address-list=SSVPN2LAN src-address-list=SSVPN_ACCESS
/ip firewall filter add action=reject chain=forward dst-address-list=SSVPN2LAN reject-with=icmp-network-unreachable

/ip firewall filter add action=accept chain=forward comment="Accept from LAN to VLAN CAMS" in-interface-list=LAN log-prefix="[VLAN CAMS]" out-interface="VLAN CAMS"

/ip firewall filter add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
/ip firewall filter add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
/ip firewall filter add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
/ip firewall filter add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
/ip firewall filter add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
/ip firewall filter add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat add action=accept chain=srcnat comment="Accept traffic to tunnel" dst-address-list=SSVPN1LAN log=yes log-prefix=atman-nat src-address-list="LAN NETWORKS" to-addresses=192.168.20.0/24
/ip firewall nat add action=accept chain=srcnat comment="Accept traffic from tunnel" dst-address-list="LAN NETWORKS" log-prefix=log src-address-list=SSVPN1LAN
/ip firewall nat add action=accept chain=srcnat comment="Accept traffic to tunnel2" dst-address-list=SSVPN2LAN log=yes log-prefix=logxx src-address-list="LAN NETWORKS"
/ip firewall nat add action=accept chain=srcnat comment="Accept traffic from tunnel2" dst-address-list="LAN NETWORKS" log-prefix=log src-address-list=SSVPN2LAN

/ip firewall nat add action=src-nat chain=srcnat out-interface-list=WAN src-address-list="LAN NETWORKS" to-addresses=my.wan1
/ip firewall nat add action=src-nat chain=srcnat out-interface-list=WAN src-address-list="!LAN NETWORKS" to-addresses=my.wan2
/ip firewall nat add action=masquerade chain=srcnat dst-address-list="VLAN NETWORKS" log-prefix=masq src-address-list="LAN NETWORKS"

/ip firewall raw add action=notrack chain=prerouting comment="Bypass IPSec traffic to vpn1 " dst-address-list=SSVPN1LAN src-address-list="LAN NETWORKS"
/ip firewall raw add action=notrack chain=prerouting comment="Bypass IPSec traffic from vpn1" dst-address-list="LAN NETWORKS" src-address-list=SSVPN1LAN
/ip firewall raw add action=notrack chain=prerouting comment="Bypass IPSec traffic to vpn2" dst-address-list=SSVPN2LAN src-address-list="LAN NETWORKS"
/ip firewall raw add action=notrack chain=prerouting comment="Bypass IPSec traffic from vpn2" dst-address-list="LAN NETWORKS" src-address-list=SSVPN2LAN
/ip firewall raw add action=drop chain=prerouting comment="drop all traffic from blacklisted addresses" src-address-list=BLACKLIST
/ip firewall raw add action=drop chain=prerouting comment="block open DNS server" dst-port=53 in-interface-list=WAN protocol=udp
/ip firewall raw add action=drop chain=prerouting comment="block open DNS server" dst-port=53 in-interface-list=WAN protocol=tcp

/ip firewall service-port set irc disabled=yes
/ip firewall service-port set sip ports=5060,5061,45670

zett93 · December 8, 2020, 10:30am

any ideas?

sindy · December 8, 2020, 11:19am

Already the action=notrack rules in chain prerouting of raw should prevent the connections from 192.168.20.0/24 or 192.168.30.0/24 to 192.168.10.0/24 from getting connection-tracked and hence NATed. So the action=accept rules in chain srcnat of nat for the same are in fact redundant - exclusion from connection tracking automatically means exclusion from NAT because NAT depends on connection tracking.

Hence the deactivation of connection tracking should not change the handling of the traffic between 192.168.20.0/24 or 192.168.30.0/24 and 192.168.10.0/24 in forward chain.

The only thing which looks suspicious to me are the following two rules:
action=src-nat chain=srcnat out-interface-list=WAN src-address-list=“LAN NETWORKS” to-addresses=my.wan1
action=src-nat chain=srcnat out-interface-list=WAN src-address-list=“!LAN NETWORKS” to-addresses=my.wan2

The thing is that srcnat acts also on traffic originated by the router itself. So if the IPsec peer is eventually linked to my.wan1, and the transport protocol used by IPsec is bare ESP because both the local and remote peers are , and the first packet goes from 192.168.20.0/24 to 192.168.10.0/24, the ESP packet carrying it will get src-nated to my.wan2, so the remote peer will ignore it (or it won’t even receive it because the packet’s source address will be different from the WAN interface’s one so the ISP will drop it).

So check whether the /ip ipsec installed-sa print shows just IP addresses as src-address and dst-address, indicating that bare ESP is in use, or ip.add.re.ss:port values, indicating that the ESP is encapsulated into UDP to traverse NAT, and thus the above theory is not applicable.

If ESP is used, do /ip firewall connection print detail where protocol~“esp” and see whether reply-dst-address is the same as src-address or different (when the IPsec connection has been started while connection tracking was enabled of course).

What also I don’t like is the connection-state=“” in one of the rules in chain forward of filter as I have no idea what this match condition actually does. In worst case this condition doesn’t match on any packet, but since there is the action=accept connection-state=…,untracked rule later on in that chain, this should not cause any issue. Similarly, the export shows to-addresses in the action=accept rule in chain srcnat of nat, which should also not cause any issue as that parameter is unused by that action.

So I’d definitely recommend to add these rules one more time before or after the existing ones, without the wrong parameters, and then remove the existing ones, but I don’t expect these changes to resolve your issue.

zett93 · December 8, 2020, 2:31pm

You got the point, in my connection tracking src-address was from my.wan1 and reply-dst-address was my.wan2.

Now, after change src-nat NAT rules all works fine, temporary all traffic will go through wan1, next i’ll tune src-nat rules.

Thanks for help, you’re great!