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?
Re: ROS Hairpin NAT - preserving origin IP for log purpose [SOLVED]
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:
You can change it to:
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.
... or something in between. You can map original subnet to some virtual subnet, e.g. if you have hairpin rule:
Code: Select all
/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=masqueradeCode: Select all
/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/24Re: ROS Hairpin NAT - preserving origin IP for log purpose
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
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
Re: ROS Hairpin NAT - preserving origin IP for log purpose
Manual says yes:
netmap - creates a static 1:1 mapping of one set of IP addresses to another one. Often used to distribute public IP addresses to hosts on private networks
-
-
DRSDavidSoft
just joined
- Posts: 2
- Joined:
- Location: California, CA
- Contact:
Re: ROS Hairpin NAT - preserving origin IP for log purpose
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 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!
Code: Select all
netmapOn 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!
Re: ROS Hairpin NAT - preserving origin IP for log purpose
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:You can change it to:Code: Select all/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=masqueradeAnd 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.Code: Select all/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
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?
Re: ROS Hairpin NAT - preserving origin IP for log purpose
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..
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..
Re: ROS Hairpin NAT - preserving origin IP for log purpose
i don't understand, do i need to put something on my web server? or only on the hairpin rule?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.
i tried with the log, and to me, both logs are the same, heres the one with the masquarade action (the working one)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..
Code: Select all
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
Code: Select all
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
Code: Select all
/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
Re: ROS Hairpin NAT - preserving origin IP for log purpose
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.
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.
Re: ROS Hairpin NAT - preserving origin IP for log purpose
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
Code: Select all
/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
Re: ROS Hairpin NAT - preserving origin IP for log purpose
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):
Code: Select all
/ip firewall mangle
add action=accept chain=prerouting dst-address=10.168.0.0/24 in-interface=bridgeLANRe: ROS Hairpin NAT - preserving origin IP for log purpose
Thanks, that worked!!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):
Code: Select all/ip firewall mangle add action=accept chain=prerouting dst-address=10.168.0.0/24 in-interface=bridgeLAN