Community discussions

MikroTik App
 
EnigmAX
just joined
Topic Author
Posts: 11
Joined: Tue May 20, 2014 9:49 pm

Hairpin nat issue

Fri May 22, 2020 9:04 pm

Hello all,

Long time Mikrotik user here, running a CCR for quite some time. While not being a network export, I can get around network topics.

Some time ago I extended my network a bit and updated my bridge configuration and started using vlan filtering. Around that time, my hairpin nat stopped working. I'm pulling the hairs out of my head, because I cannot find the reason why.

I'm trying to access a webserver in my network, with my external ip-address on port 80 and/or 443. From the outside network, this is working perfectly fine. From the inside however, it doesn't (anymore). When I try to access my webserver from inside (on the external ip), I see the dstnat rule is processing, but the srcnat masquerading tool does not seem to match (counter remains 0).

The connection times out.
Tcpdump on my webserver shows no sign of traffic when I try to access from the inside.
Gateway on webserver is correct. (hence, dstnat is working fine)
Client and webserver on the inside are on the same subnet.

So I enabled logging and I do see some strange things (to me) like this:
dstnat: in:bridge-hq(ether7-trunk-zolder) [b]out:(unknown 0)[/b], src-mac 9c:5c:8e:bc:88:8b, proto TCP (SYN), 10.52.10.134:51750->83.68.xxx.yyy:443, len 52
This "out:(unknown 0)" is bothering me.

I think I might be missing some detail, have been checking this out for a few nights now, but can't find the reason. Hopefuly any of you can put me on the right tracks again.

My configuration (hide-sensitive):
snip
Last edited by EnigmAX on Sat May 23, 2020 12:26 am, edited 1 time in total.
 
anav
Forum Guru
Forum Guru
Posts: 4261
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Hairpin nat issue

Fri May 22, 2020 10:46 pm

Very complex for me to look at and understand but from what I can see nothign wrong with your dstnat nat rules.
Your source nat configuration is beyond me, but lets assume its okay.

My two concerns are :

(1) the fw rules -
a. in general I dont like them and would reset those to defaults and then look at what you have now and see what you have to modify.
b. In particular I dont see one that denies wan inputs for everying but new dstnat connections (default rule) or
I dont see one explicity allows wan inputs for dstnat connections (my preferred rule - in combination with a last forward rule of drop all else)

2. Hairpin NAT is only required when you want LAN users to access a LAN server, WHERE the users and server are in the SAME subnet.
If the server and lan users are on different subnets, this is not a hairpin nat scenario.

The other requirement in your case is a hairpin SOURCE NAT RULE in the following format..
chain=srcnat action=masquerade dst-address=192.168.88.0/24 src-address=192.168.88.0/24
replace with subnet of your choice.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 5483
Joined: Mon Apr 20, 2009 9:11 pm

Re: Hairpin nat issue  [SOLVED]

Sat May 23, 2020 12:09 am

The "out:(unknown 0)" is fine, because in dstnat it's not yet known where the packet will go, it's decided later. But I don't see anything clearly wrong either. If you have hits for dstnat and not for srcnat, then something should be blocking it in forward. But the only rule that could do this is the last one for blocking connection-state=invalid, which should not do it, I don't see a reason why it would be invalid (*). You can test it with logging rule, e.g.:
/ip firewall filter
add chain=forward src-address=10.52.10.134 dst-address=10.52.10.46 protocol=tcp dst-port=443 action=log
Put it at the top and it should log something. Then move it to the bottom and see if it changes.

(*) The only suspect would be bridge's use-ip-firewall=yes, use-ip-firewall-for-vlan=yes. I prefer to avoid these options, because the behaviour is sometimes unexpected.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
EnigmAX
just joined
Topic Author
Posts: 11
Joined: Tue May 20, 2014 9:49 pm

Re: Hairpin nat issue

Sat May 23, 2020 12:24 am

I added the log rule, I was already checking on prerouting, forwarding, postrouting to figure out where stuff was going south. However, this did not help anything. Traffic not reaching forwaring at all I guess.
(*) The only suspect would be bridge's use-ip-firewall=yes, use-ip-firewall-for-vlan=yes. I prefer to avoid these options, because the behaviour is sometimes unexpected.
This one was a winner advice!
Honestly, I did look over this one. I created a completely new bridge and as far as I can remember I did not mess around with the bridge settings (it should be disabled by default, according to the documentation here: https://wiki.mikrotik.com/wiki/Manual:I ... e_Settings).

Everything working again as expected now. Good catch, thank you!
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Hairpin nat issue

Sat May 23, 2020 12:41 am

I suspect that the issue is caused by
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-vlan=yes

which is not compensated for.

If you look at the log line you've quoted, it says in:bridge-hq(ether7-trunk-zolder), whereas it should actually say in:hq-vlan10. So the rule acts too early, already when the frame is processed at bridge level, which breaks something in the subsequent processing.

To fix that, it might be sufficient to add in-interface=!bridge-hq to the rule.
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.
 
EnigmAX
just joined
Topic Author
Posts: 11
Joined: Tue May 20, 2014 9:49 pm

Re: Hairpin nat issue

Sat May 23, 2020 12:47 am


If you look at the log line you've quoted, it says in:bridge-hq(ether7-trunk-zolder), whereas it should actually say in:hq-vlan10. So the rule acts too early, already when the frame is processed at bridge level, which breaks something in the subsequent processing.

To fix that, it might be sufficient to add in-interface=!bridge-hq to the rule.
Yes, you are completely correct on this. In the meantime, I disabled use-ip-firewall and use-ip-firewall-for-vlan on the bridge settings, because I do not need them.

I could've come to the same conclusion if I would've been a little smarter: I do recall wondering about all the devices mentioned when I was torching/sniffing the traffic :)

Thanks for your help and your explanation (for future use), it is working again! :)
 
Sob
Forum Guru
Forum Guru
Posts: 5483
Joined: Mon Apr 20, 2009 9:11 pm

Re: Hairpin nat issue

Sat May 23, 2020 12:50 am

But now if you disabled it, you'll want to do something with firewall filter, because it allows pretty much anything to pass.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
EnigmAX
just joined
Topic Author
Posts: 11
Joined: Tue May 20, 2014 9:49 pm

Re: Hairpin nat issue

Sat May 23, 2020 12:54 am

But now if you disabled it, you'll want to do something with firewall filter, because it allows pretty much anything to pass.
Yes, I completely agree. Input is pretty much blocked from the outside. Forwarding however is almost allowed anywhere, with the exception of some bogon rules and invalid states. This needs to be sorted out asap, I agree.

For what it's worth; there wasn't any filtering going on at bridge level anyway. So no big change there.
 
Sob
Forum Guru
Forum Guru
Posts: 5483
Joined: Mon Apr 20, 2009 9:11 pm

Re: Hairpin nat issue

Sat May 23, 2020 1:06 am

I didn't think it through, it was just that the last rule for invalid packets blocked this, and a quick thought that maybe something else what was invalid before and blocked isn't now. But probably not.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.

Who is online

Users browsing this forum: Bing [Bot], jvanhambelgium, Lemahasta, usernews and 67 guests