Community discussions

MikroTik App
 
User avatar
bekax5
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Thu Apr 30, 2015 11:27 pm

Masquerade IPSec/IKEv2 traffic from Road Warrior

Fri May 14, 2021 2:31 am

Hello,
I have an iOS Phone that connects via IKEv2 to the main router.
The router has a Site 2 Site VPN connection via Routing-Mark in Mangle.

I see this Road Warrior trying to connect to the VPN through the correct interface, so seems Mangle rules for routing-mark are applied correctly..
However it has the source address of the IKEv2 pool (192.168.200.199/32) which is different from the main LAN subnet (192.168.1.0/24), and thus not recognized by the remote VPN site (192.168.2.0/24).
Is there anyway to masquerade the traffic from IKEv2 that goes to the VPN ?

I tried a generic masquerade but it didn't work, and a src-nat didn't either.
Traffic never reaches these rules...
7  chain=srcnat action=src-nat to-addresses=192.168.1.250 src-address=192.168.200.199 dst-address=192.168.2.0/24 log=no log-prefix=""
8  chain=srcnat action=masquerade src-address=192.168.200.199 dst-address=192.168.2.0/24 log=no log-prefix=""

Any tip for this?
 
User avatar
bekax5
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Thu Apr 30, 2015 11:27 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior

Sun May 16, 2021 12:41 pm

Bump :)
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior

Sun May 16, 2021 12:48 pm

The only thing to come to my mind is that other rules in the srcnat chain of nat shadow the two you've posted. The posted rules themselves should do what you expect them to do.
 
User avatar
bekax5
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Thu Apr 30, 2015 11:27 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior

Sun May 16, 2021 3:21 pm

I pulled the src-nat rule to the first position.
And the last rule in Mangle is being hit with traffic:
23    chain=postrouting action=accept src-address=192.168.200.199 dst-address=192.168.2.0/24 log=no log-prefix=""

 0    chain=srcnat action=masquerade src-address=192.168.200.199 dst-address=192.168.2.0/24 log=no log-prefix=""
With this there's still no traffic in NAT! Not sure what's happening.
What's fact is that traffic is reaching the remote VPN Router (192.168.2.0/24 network)..
I'll have to reboot later today since it doesn't make sense..
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior  [SOLVED]

Sun May 16, 2021 3:58 pm

The packet passes through the postrouting chain of mangle before getting to chain srcnat of nat, see this diagram. So the only way to see what happened in src-nat is by sniffing on the out-interface, of course if IPsec policy hasn't matched and encrypted the packet. Or you can see it on the remote system if you can manage it.

Questions:
  • do you realize that only the initial packet of a connection is matched against the rules in nat, and their verdict is stored in connection tracking and same or mirror treatment is applied to subsequent packets of that connection depending on their direction?
  • do you realize that if you apply action=notrack on a packet in /ip firewall raw, that packet bypasses also any NAT handling, as NAT is just one of functionalities of conntrack?
 
User avatar
bekax5
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Thu Apr 30, 2015 11:27 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior

Tue May 18, 2021 12:05 am

The packet passes through the postrouting chain of mangle before getting to chain srcnat of nat, see this diagram. So the only way to see what happened in src-nat is by sniffing on the out-interface, of course if IPsec policy hasn't matched and encrypted the packet. Or you can see it on the remote system if you can manage it.

Questions:
  • do you realize that only the initial packet of a connection is matched against the rules in nat, and their verdict is stored in connection tracking and same or mirror treatment is applied to subsequent packets of that connection depending on their direction?
  • do you realize that if you apply action=notrack on a packet in /ip firewall raw, that packet bypasses also any NAT handling, as NAT is just one of functionalities of conntrack?
You were right!
I had an action=notrack rule in /ip firewall raw which I totally forgot. I had it to Fasttrack bypass IKEv2 traffic.

I changed them into
/ip firewall filter
1    chain=forward action=accept src-address=192.168.200.0/24 log=no log-prefix="" 
2    chain=forward action=accept dst-address=192.168.200.0/24 log=no log-prefix=""
And that solved my issue.
Thanks a lot ! (again) :)

Something not related to the first issue,
I noticed in the Wiki that those Firewall Filter rules to bypass Fasttrack with ipsec traffic, should have connection-state=established,related,
but won't those always be skipped because initial packet never matches?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior

Fri May 21, 2021 8:30 pm

I noticed in the Wiki that those Firewall Filter rules to bypass Fasttrack with ipsec traffic, should have connection-state=established,related,
but won't those always be skipped because initial packet never matches?
All rules matching on connection-state=established,related will be skipped by any initial packet, including the rule with action=fasttrack-connection. So after all those with connection-state=established,related, you can place rules selectively permitting initial packets depending on multiple criteria, thus allowing new connections to establish.

The currently provided default firewall rules for SOHO devices assume that whatever is handled by IPsec is considered to be secure, hence these rules
(action=accept ipsec-policy=in,ipsec and action=accept ipsec-policy=out,ipsec) do not check for connection-state. But you can still add that match condition to them, and vice versa, you may add the ipsec-policy=in,ipsec match condition to the selective permissive rules for initial packets, allowing some connections to establish only if they came in via an IPsec SA, or even vice versa, to allow them to establish only if they did not come via an SA if you let them match on ipsec-policy=in,none.

(two more connection-state values exist, invalid and untracked, so strictly speaking you either have to place rules matching on these connection-state values before those intended to handle only the initial packets, or you must put the match condition connection-state=new to every rule intended to selectively handle only the initial packets).
 
User avatar
bekax5
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Thu Apr 30, 2015 11:27 pm

Re: Masquerade IPSec/IKEv2 traffic from Road Warrior

Wed May 26, 2021 8:20 pm

Awesome!
Honestly I became a bit confused with the "NAT and Fasttrack Bypass" Wiki.
I had a feeling it could have something to do with the first packets though.

I'm always learning a lot with you.
Thanks so much.

Who is online

Users browsing this forum: tangent and 82 guests