ROS Hairpin NAT - preserving origin IP for log purpose

RouterOS General
1

Just say thats not possible because of design, but maybe its some workaround here…

1, I have a hairpin NAT for LAN connections on local bridge - fully functional, no problems.
2, If someone from LAN connect to another LAN machine (server) with public IP - it works, but in server log is IP of local bridge (yes its normal behaviour).
3, Question is: Can I FORCE somehow to keep IP of original source IP ?

Please I just need to log real source IP on server, is there any mangle, post or pre routing magic?

2

You can’t have real source address, that’s impossible. It’s what you have without hairpin and it doesn’t work. Hairpin makes it work, but you lose the real source address. It’s a tradeoff, you can have one or another…

… or something in between. You can map original subnet to some virtual subnet, e.g. if you have hairpin rule:

/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=masquerade

You can change it to:

/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=netmap to-addresses=10.168.88.0/24

And server will see 10.168.88.x, which is not real address, but you’ll know that it means 192.168.88.x. It’s not perfect, but better than nothing.

3

Your workaround with netmap looks interesting.
It seems that last octet in netmaped address is always real octet from lan network.
I am happy, if I can rely on that behaviour, I am able to identify real source IP.

Thank you for your magic advice :slight_smile:

4

Manual says yes:

5

I’m sorry for reviving this old thread – I just wanted to say how much I appreciate this solution! I have been looking for a way to solve this exact issue to no avail, and it never occurred to me that

netmap

can be used in such a way.

On the server side, I just need to do a quick string replace, and I can now have the originating IP. This is truly a magical solution!

6

i tried this but cant make it work

my current hairpin rule is the same as the 1st one here, and changed to make it look like the 2nd one, and with that i can’t access my local web server from my lan (using my public ip or url), what else can i check?

7

Route to virtual addresses (10.168.88.0/24 or whatever you used) on web server machine must point to router where you’re doing this. You don’t need to add anything, it’s covered by default route, if it points to this router. Basically it would be a problem only if server had route to this subnet going elsewhere.

If it’s not this, then it’s probably just some small mistake, typo, …

As always, it helps to watch what happens, go step by step and find out where it fails. Dstnat is ok, you didn’t change that. Srcnat for hairpin, if you didn’t do other modifications, is pretty much the same. But you can verify (using Tools->Torch or logging rules in postrouting) that you see packets from 10.168.88.x going to server, if server sees them, accepts connections, send anything back, etc..

8

i don’t understand, do i need to put something on my web server? or only on the hairpin rule?

As always, it helps to watch what happens, go step by step and find out where it fails. Dstnat is ok, you didn’t change that. Srcnat for hairpin, if you didn’t do other modifications, is pretty much the same. But you can verify (using Tools->Torch or logging rules in postrouting) that you see packets from 10.168.88.x going to server, if server sees them, accepts connections, send anything back, etc..

i tried with the log, and to me, both logs are the same, heres the one with the masquarade action (the working one)

masq:  srcnat: in:(unknown 0) out:bridgeLAN, src-mac 04:d4:c4:53:46:52, proto TCP (SYN), 192.168.0.30:25310->192.168.0.15:80, NAT 192.168.0.30:25310->(201.171.144.99:80->192.168.0.15:80), len 52

and heres the one with the netmap action

netmap:  srcnat: in:(unknown 0) out:bridgeLAN, src-mac 04:d4:c4:53:46:52, proto TCP (SYN), 192.168.0.30:25308->192.168.0.15:80, NAT 192.168.0.30:25308->(201.171.144.99:80->192.168.0.15:80), len 52

here are my nat rules, i disable one hairpin rule and enable the other to test, maybe i forgot to tell you guys that i have two WAN, one cable and one dsl, the cable WAN is behind a NAT so ports are closed, i use the DSL as the gateway of my servers, from the outside all works ok and with the 1st hairpin rule, from the inside my server is reachable with my DSL public ip address.

/ip firewall nat
add action=masquerade chain=srcnat comment="Hairpin NAT Masq" dst-address=\
    192.168.0.0/24 log=yes log-prefix="masq: " src-address=192.168.0.0/24
add action=netmap chain=srcnat comment="Hairpin NAT Masq" disabled=yes \
    dst-address=192.168.0.0/24 log=yes log-prefix="netmap: " src-address=\
    192.168.0.0/24 to-addresses=10.168.0.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    out-interface=ether1-WAN1
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    out-interface=pppoe-Telnor
add action=dst-nat chain=dstnat dst-address-list=WAN2-ADDR dst-address-type=\
    "" dst-port=80 protocol=tcp to-addresses=192.168.0.15 to-ports=80
9

You most likely do not need to do anything with server. The problem I mentioned would occur only if for example you’d already have 10.168.0.0/24 assigned to server’s other interface, or if it would be used somewhere else and server would have route to it via another router than this one.

One thing that could influence it on server would be its firewall, if it blocked packets from 10.168.0.0/24. But it’s not very likely that you’d have service accessible from internet and for some reason blocked access from some private subnets.

Since you mentioned two WANs, is there something interesting in “/ip firewall mangle”, like marking routing for some packets? Or some rules in “/ip route rule”? If there is, you need to exclude packets from server to 10.168.0.0/24 from that.

10

i use some mangle rules to be able to redirect traffic to my 2nd wan, only need to put the ip in a list and those goes to the 2nd wan, here are my mangle and route rules

/ip route
add check-gateway=ping distance=1 gateway=pppoe-Telnor routing-mark=TelnorWAN
add check-gateway=ping distance=2 gateway=8.8.4.4

/ip firewall mangle
add action=accept chain=prerouting comment="Telnor metodo 2" \
    dst-address-list=WAN2-ADDR in-interface=bridgeLAN
add action=mark-connection chain=prerouting connection-mark=no-mark \
    in-interface=pppoe-Telnor new-connection-mark=Telnor_Conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=bridgeLAN new-connection-mark=\
    Telnor_Conn passthrough=yes src-address-list=TelnorList
add action=mark-routing chain=prerouting connection-mark=Telnor_Conn \
    dst-address-type="" in-interface=bridgeLAN new-routing-mark=TelnorWAN \
    passthrough=yes src-address-list=TelnorList
add action=mark-routing chain=output connection-mark=Telnor_Conn \
    new-routing-mark=TelnorWAN passthrough=yes src-address-list=TelnorList
11

I’m not sure which WAN is which and if the server is part of list, but this should do the trick (before other rules):

/ip firewall mangle
add action=accept chain=prerouting dst-address=10.168.0.0/24 in-interface=bridgeLAN
12

Thanks, that worked!!