Hello,
I recently posted about having a Hairpin NAT issue. This time I’m configuring it to access my home server behind traefik.
I followed the configuration outlined in this post and have not been able to get it to work.
Last time the issue was my firewall rule regarding allowing port-forwarding and it being set to allow on WAN interfaces.
I upgraded to router to long-term and rebooted with no avail.
Configuration included.
export.rsc (8.27 KB)
(1) Out of order input chain rules and they need work. FIXED!!! DOnt need connection state-new on your rules…
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp \
src-address-list=CroatiaIPList
add action=accept chain=input comment="Allow Router-ACCESS only for ADMIN" \
in-interface=bridge src-address-list="Home Users"
add action=accept chain=input comment=\
"Allow access to router dns services for all users" \
dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment=\
"Allow access to router dns services for all users" \
dst-port=53 in-interface-list=LAN protocol=udp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=drop chain=input comment="Drop everything else"
(2) However the second last rule is basically useless.
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN
a. it contradicts previous rules where you only want the admin to access the router and this rule allows anyone on the LAN to access the full router
b. you have the drop rule next so all traffic will be dropped at this point regardless…
(4) Forward chain order and dont need NEW…
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid log=yes log-prefix=drop-invalid
add action=accept chain=forward comment="Allow port forwarding" \
connection-nat-state=dstnat
add action=accept chain=forward comment="Internet Access" in-interface-list=\
LAN out-interface-list=WAN
add action=drop chain=forward comment="Drop everything else
(5) Hairpin NAT rule is incomplete???
/ip firewall nat
add action=masquerade chain=srcnat comment=“Hairpin NAT” connection-mark=
Hairpin-NAT
Can you explain again why you are attempting to mangle traffic for hairpin nat ???
Did you add 10.20.0.0/24 and 10.20.10.0/24 in CroatiaIPList list?
@anav: Marking is based on linked post. It can be done without it, but it’s not wrong, just slightly different approach. On the upside, it does srcnat only for connections that 100% need hairpin NAT. In this case I don’t see any added value, but it could help with some configs, e.g. with VPNs where clients get addresses from LAN range.
Hy, thanks for the quick reply.
Want to do testing and just homelab type of stuff at home.
Example: I have a website hosted in homelab and want to use traefik as reverse-proxy so that when i go to nginx.example.com it goes to that nginx instance but when I go to portfolio.example.com it goes to a portfolio website.
Mangle because I seen it used in the mentioned post. And other services I want to be able to connect access them with a public IP while ill local network.
jesus… sometimes I just feel dumb… That was the problem. Thanks!
Also thanks to @anav for fix unrelated to this post its actually really appreciated.
Indeed for VPN and so it doesn’t touch any other traffic.
But you don’t seem to have such VPN.
And before @anav asks, it’s when you have e.g. LAN 192.168.88.0/24, but instead of using different subnet for VPN clients (like 192.168.89.0/24), you give them also 192.168.88.x, and enable proxy ARP on LAN interface. Reason for doing so could be if you’re lazy to change other devices’ firewalls that by default allow access only from local subnet. If the source is another 192.168.88.x, to them it seems local, even if it’s not. Another reason was when older Windows didn’t have any good way how to add routes for VPN connections, so you could either route everything via VPN (including access to internet), or you had to manually add routes to different remote subnets. But if client got 192.168.88.x, it automatically added route to 192.168.88.0/24. It’s not needed anymore in newer versions (I think it’s since Win10), because they have mechanism for adding routes. The problem with usual hairpin NAT rule (with just src/dst-address=) is that it matches even connection from remote VPN client 192.168.88.x to local server 192.168.88.y.
Okay I get a bit of it, basically ones marks connections for all LAN users headed towards the WANs in pre-routing.
Then in source nat rules any traffic with those markings are masqueraded to the outgoing interface…
Not sure how that equates to hairpin nat though…
Hairpin NAT is that srcnat rule used for traffic from LAN client to LAN server via WAN address. It happens here too. If it’s from LAN to WAN address, it gets marked. If there’s dstnat from WAN address to LAN, it goes back to LAN. If it was marked, it gets masqueraded.
Very nice, but I think I need the long winded MKX explanation LOL.
In any case you intimated that this could be used to differentiate users EVEN if from the same subnet???
If you want to, and if simple netmap for whole subnet (as described in this post in your thread) isn’t good enough, and if I’m not misunderstanding what you mean, then yes. But I still find it mostly pointless. What would you do with it?