Community discussions

MikroTik App
 
networknoob88
newbie
Topic Author
Posts: 45
Joined: Sun Jul 15, 2018 6:00 pm

Site-to-Site IPsec VPN IP filter firewall rules clarification

Tue Jun 30, 2020 11:37 am

I set up a S2S IPsec tunnel between my CCR and a Fortigate after consulting some online documentation. It worked fine, but I realized that these are the only two IP firewall filter rules I needed to make it work:
 chain=forward action=accept src-address=<remote-subnet> in-interface=<my-WAN> ipsec-policy=in,ipsec
 chain=forward action=accept dst-address=<remote-subnet> out-interface=<my-WAN> ipsec-policy=out,ipsec 

These were placed above the fasttrack forwards and the standard set of "accept established/related and deny invalids/others etc" firewall rules. Here I omitted those rules as well as the src-nat rules and the actual IPsec configurations because those are not relevant to this topic.

My question is why it's working without any kind of (input?) rules that allow the two routers themselves to establish and negotiate the tunnel?

Both routers have public WAN IPs. During negotiation, aren't the initial traffic supposed to be "input" between the two WAN IPs? Since I have no such rules in my CCR, and the input chain is standard "accept established/related, accept local LAN, deny all others" configuration, does it mean my tunnel was established solely based on outbound request sent from my CCR, accepted by the remote router, and from there they become "established/related"?

Also I configured no IPsec ports or protocols in the filter either, were those taken care of by " ipsec-policy=in,ipsec" and "ipsec-policy=out,ipsec"?
 
sindy
Forum Guru
Forum Guru
Posts: 5342
Joined: Mon Dec 04, 2017 9:19 pm

Re: Site-to-Site IPsec VPN IP filter firewall rules clarification

Wed Jul 01, 2020 12:48 am

My question is why it's working without any kind of (input?) rules that allow the two routers themselves to establish and negotiate the tunnel?
Since the default firewall rules form up a stateful firewall, where the first rule in chain input of table filter says "accept (packets belonging to) established or related (connections)", and since you've probably allowed both peers to initiate the connection rather than passively respond incoming connections, both send packets to each other from the same UDP ports on which they listen (500), and hence at Mikrotik side, the initial packet from the Fortigate is treated as if it belonged to the connection initiated by the Mikrotik itself.

The same applies for ESP (the packets transporting the actual payload) if at least one LAN host at each site actively send something to at least one LAN host on the remote site. The ESP packets are sent and received by the router itself, so they are also handled by chains input and ouput.

If all clients were at one site and all servers on the other one, the server site's IPsec gateway would not accept the incoming ESP. Unlike other protocols (ftp, pptp), there is no "helper" which would create a "related" connection for the ESP based on the contents of the IKE(v2) exchange. So manually configured accept rules or the mechanism described above are the only ways to make the firewall accept incoming ESP packets for the router itself.

Also I configured no IPsec ports or protocols in the filter either, were those taken care of by " ipsec-policy=in,ipsec" and "ipsec-policy=out,ipsec"?
No. Why the transport packets (ESP) get through is explained above. ipsec-policy=in,ipsec matches all packets which came to the router via an IPsec SA, i.e. which have been decapsulated from the transport ones; ipsec-policy=out,ipsec matches all packets whose protocol headers match any active policy so they will be matched by any of the available IPsec SAs and encapsulated into ESP. The assumption here is that you don't need firewalling between the two sites so the fact that the packets came in or are going to be sent out via an IPsec tunnel is a sufficient qualification for them to get accepted. In the forward chain in particular, these rules accepting any IPsec payload packets are intentionally placed before the action=fasttrack-connection one, because once a connection gets fasttracked, most of its packets bypass many layers of firewall handling and of IPsec traffic selector matching (which is the very essence of fasttracking), so we need to prevent the connections which need IPsec matching from ever getting fasttracked.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
networknoob88
newbie
Topic Author
Posts: 45
Joined: Sun Jul 15, 2018 6:00 pm

Re: Site-to-Site IPsec VPN IP filter firewall rules clarification

Wed Jul 01, 2020 5:03 am

My question is why it's working without any kind of (input?) rules that allow the two routers themselves to establish and negotiate the tunnel?
Since the default firewall rules form up a stateful firewall, where the first rule in chain input of table filter says "accept (packets belonging to) established or related (connections)", and since you've probably allowed both peers to initiate the connection rather than passively respond incoming connections, both send packets to each other from the same UDP ports on which they listen (500), and hence at Mikrotik side, the initial packet from the Fortigate is treated as if it belonged to the connection initiated by the Mikrotik itself.

The same applies for ESP (the packets transporting the actual payload) if at least one LAN host at each site actively send something to at least one LAN host on the remote site. The ESP packets are sent and received by the router itself, so they are also handled by chains input and ouput.

If all clients were at one site and all servers on the other one, the server site's IPsec gateway would not accept the incoming ESP. Unlike other protocols (ftp, pptp), there is no "helper" which would create a "related" connection for the ESP based on the contents of the IKE(v2) exchange. So manually configured accept rules or the mechanism described above are the only ways to make the firewall accept incoming ESP packets for the router itself.

Also I configured no IPsec ports or protocols in the filter either, were those taken care of by " ipsec-policy=in,ipsec" and "ipsec-policy=out,ipsec"?
No. Why the transport packets (ESP) get through is explained above. ipsec-policy=in,ipsec matches all packets which came to the router via an IPsec SA, i.e. which have been decapsulated from the transport ones; ipsec-policy=out,ipsec matches all packets whose protocol headers match any active policy so they will be matched by any of the available IPsec SAs and encapsulated into ESP. The assumption here is that you don't need firewalling between the two sites so the fact that the packets came in or are going to be sent out via an IPsec tunnel is a sufficient qualification for them to get accepted. In the forward chain in particular, these rules accepting any IPsec payload packets are intentionally placed before the action=fasttrack-connection one, because once a connection gets fasttracked, most of its packets bypass many layers of firewall handling and of IPsec traffic selector matching (which is the very essence of fasttracking), so we need to prevent the connections which need IPsec matching from ever getting fasttracked.

Thanks so much for the clarification. It makes sense now.

So to be safe, I added two INPUT rules for the WAN interface/destination, one accepts ipsec-esp (protocol 50) and the other accepts UDP 500/4500 from the remote gateway IP, this should be the most fail-proof setup that will also take care of the "all servers on one side and clients on the other" scenario, right?

Who is online

Users browsing this forum: Danielmhmdi, eworm, msatter, prislonsky, sakalsk, StephenL and 66 guests