Hello,
Right now I have a RB3011 router and a CRS326 switch at home. Since I don't want to open up ports from the internet into my LAN I'm going to configure a DMZ and put my server here where it will be "isolated" from the rest of the LAN.
Right now if I try to access my external IP from my LAN I will get directed to my router. I can "fix" this by configuring Hairpin NAT.
That way I can point www.example.com to my external IP and get to the correct site. Without Hairpin NAT I will get to my routers webUI.
My question is if I can add a second network cable from my ISPs modem (yes I can get more than 1 IP) and make my DMZ use this IP and my LAN use the first one and have the LAN-traffic access the DMZ external IP without using Hairpin NAT?
I hope you understand what I mean.
Since the LAN won't be able to access the internal IP of the DMZ I can't configure an internal DNS server to point to the internal DMZ IP.
I just want to be able to access www.example.com on it's external IP from inside my LAN.
Is this possible or is Hairpin NAT the only way? I've read somewhere that you should avoid hairpin nat on production. Why is that? Is it adding unnecessary overhead on the router or something?
Re: Accessing external IP from LAN without hairpin NAT
Quick answer is - yes, if you use second IP for webserver, you don't need hairpin-nat. And you don't need the internal DNS server point to DMZ IP, point it to external IP. Be sure to not use default masquerade, use src-nat to appropriate extarnal IPs instead.
Re: Accessing external IP from LAN without hairpin NAT
You don't even need a hairpin NAT, it is enough to place the server and the client into different LAN subnets.
Two WAN IPs on the same machine will cause the traffic to be routed directly, bypassing the physical uplink(s), so if your dst-nat rules refer to in-interface(-list) as they should, it would be surprising.
Two WAN IPs on the same machine will cause the traffic to be routed directly, bypassing the physical uplink(s), so if your dst-nat rules refer to in-interface(-list) as they should, it would be surprising.
Re: Accessing external IP from LAN without hairpin NAT
@sindy
Some questions.
Assumption: OP does not want OPEN PORTS on the router - ie ports accessible to the outside world. - A very reasonable consideration.
Solutions:
1. Standard Solution: Simply use the LANIP of the server from subnets behind the router
server on subnet A
users in subnet A simply enter in lanip of server
users in subnet B, if not on the same bridge, or in vlans, simply make a specific firewall rule allowing vlanb to vlana source is interfaceB, destination IP is server.
2. Bizarro Solution (without hairpin): Still attempt to use the WANIP of the router to reach the server. ME NO COMPRENDO why one would want to do this so the OP has me confused LOL.
Server on subnet A
Users on subnet B - This is normal behaviour no hairpin is required and meets the needs of the OP as Sindy described. MAYBE
@Sindy - but I have some concerns.
1. Do we still need a DST NAT RULE - I assume yes!!
2. Do we still need a FW rule - I assume yes.
Typically its like this
add action=accept chain=forward comment=\
"Allow Port Forwarding - DSTNAT" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
OR
if using the default rule that does the same thing
add action=drop chain=forward connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
RESULT - THe port is still open to the outside world BREAKING the ops requirement!!!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I believe this is a case where Sobs routing cruel trickery is the right answer......................
/ip route rule
add action=lookup-only-in-table dst-address=x.x.x.0/24 table=main
I have no idea what this does, other then perhaps intercept traffic headed to the server and redirect it to the server .......magically.
Not sure of the right setup or if any mangle is required.
But I think this will accomplish the same behaviour of hairpin nat, OR as sindy pointed out, normal nat when server is in subnet A and users are on subnet B.
BUT without opening any ports.
In other words, the user can disable the port fowarding firewall filter rule in the FORWARD CHAIN and thus close the server off from the outside world.
Some questions.
Assumption: OP does not want OPEN PORTS on the router - ie ports accessible to the outside world. - A very reasonable consideration.
Solutions:
1. Standard Solution: Simply use the LANIP of the server from subnets behind the router
server on subnet A
users in subnet A simply enter in lanip of server
users in subnet B, if not on the same bridge, or in vlans, simply make a specific firewall rule allowing vlanb to vlana source is interfaceB, destination IP is server.
2. Bizarro Solution (without hairpin): Still attempt to use the WANIP of the router to reach the server. ME NO COMPRENDO why one would want to do this so the OP has me confused LOL.
Server on subnet A
Users on subnet B - This is normal behaviour no hairpin is required and meets the needs of the OP as Sindy described. MAYBE
@Sindy - but I have some concerns.
1. Do we still need a DST NAT RULE - I assume yes!!
2. Do we still need a FW rule - I assume yes.
Typically its like this
add action=accept chain=forward comment=\
"Allow Port Forwarding - DSTNAT" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
OR
if using the default rule that does the same thing
add action=drop chain=forward connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
RESULT - THe port is still open to the outside world BREAKING the ops requirement!!!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I believe this is a case where Sobs routing cruel trickery is the right answer......................
/ip route rule
add action=lookup-only-in-table dst-address=x.x.x.0/24 table=main
I have no idea what this does, other then perhaps intercept traffic headed to the server and redirect it to the server .......magically.
Not sure of the right setup or if any mangle is required.
But I think this will accomplish the same behaviour of hairpin nat, OR as sindy pointed out, normal nat when server is in subnet A and users are on subnet B.
BUT without opening any ports.
In other words, the user can disable the port fowarding firewall filter rule in the FORWARD CHAIN and thus close the server off from the outside world.
Re: Accessing external IP from LAN without hairpin NAT
Thanks for the reply's.@sindy
Some questions.
Assumption: OP does not want OPEN PORTS on the router - ie ports accessible to the outside world. - A very reasonable consideration.
Solutions:
1. Standard Solution: Simply use the LANIP of the server from subnets behind the router
server on subnet A
users in subnet A simply enter in lanip of server
users in subnet B, if not on the same bridge, or in vlans, simply make a specific firewall rule allowing vlanb to vlana source is interfaceB, destination IP is server.
2. Bizarro Solution (without hairpin): Still attempt to use the WANIP of the router to reach the server. ME NO COMPRENDO why one would want to do this so the OP has me confused LOL.
Server on subnet A
Users on subnet B - This is normal behaviour no hairpin is required and meets the needs of the OP as Sindy described. MAYBE
@Sindy - but I have some concerns.
1. Do we still need a DST NAT RULE - I assume yes!!
2. Do we still need a FW rule - I assume yes.
Typically its like this
add action=accept chain=forward comment=\
"Allow Port Forwarding - DSTNAT" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
OR
if using the default rule that does the same thing
add action=drop chain=forward connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
RESULT - THe port is still open to the outside world BREAKING the ops requirement!!!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I believe this is a case where Sobs routing cruel trickery is the right answer......................
/ip route rule
add action=lookup-only-in-table dst-address=x.x.x.0/24 table=main
I have no idea what this does, other then perhaps intercept traffic headed to the server and redirect it to the server .......magically.
Not sure of the right setup or if any mangle is required.
But I think this will accomplish the same behaviour of hairpin nat, OR as sindy pointed out, normal nat when server is in subnet A and users are on subnet B.
BUT without opening any ports.
In other words, the user can disable the port fowarding firewall filter rule in the FORWARD CHAIN and thus close the server off from the outside world.
I think you misunderstood me here. I have no problem opening up ports to the internet As long as it's to a DMZ. I don't want to open, lets say port 80, to a server on my LAN.
That's the reason I want a DMZ to put my webserver here so it's isolated from the rest of the LAN.
But I still want to be able to access www.example.com both from inside the LAN and from the internet without using split-brain DNS since the internal DMZ network wont be accessible from the LAN network anyway.
I'm glad to get any information on this so I can try this out during the weekend.
Re: Accessing external IP from LAN without hairpin NAT
Hi Patric,
Thanks for the extra information.
This is all doable with one WANIP.
Just put the server on its own subnet (not on a bridge with the rest of the LAN) or in a VLAN (can be on same bridge then).
Then by firewall rules, the LAN and server are separate (assuming use of drop all rule as last rule in forward chain).
Done!
Users on the Internet can access the server by your WANIP (typically by dyndns name/url)
Users on the LAN can access the server by the WANIP (using dydndns name/url)
You still can allow users on the LAN to access the server by LANIP (or in this case vlan IP) by simply creating a one way firewall rule from lan subnet to the server on the vlan.
basically - in-interface=lansubnet out-interface=vlanserver (and if you want more specificity - dst-address=ip of server)
@sindy, however I still want to know how one would redirect subnet users to access the vlan or different subnet server, BY THE WANIP, but without a forward firewall rule for dstnat.
(How to apply Sobs rules for routing the request .........)
Thanks for the extra information.
This is all doable with one WANIP.
Just put the server on its own subnet (not on a bridge with the rest of the LAN) or in a VLAN (can be on same bridge then).
Then by firewall rules, the LAN and server are separate (assuming use of drop all rule as last rule in forward chain).
Done!
Users on the Internet can access the server by your WANIP (typically by dyndns name/url)
Users on the LAN can access the server by the WANIP (using dydndns name/url)
You still can allow users on the LAN to access the server by LANIP (or in this case vlan IP) by simply creating a one way firewall rule from lan subnet to the server on the vlan.
basically - in-interface=lansubnet out-interface=vlanserver (and if you want more specificity - dst-address=ip of server)
@sindy, however I still want to know how one would redirect subnet users to access the vlan or different subnet server, BY THE WANIP, but without a forward firewall rule for dstnat.
(How to apply Sobs rules for routing the request .........)
Re: Accessing external IP from LAN without hairpin NAT
That's what I've suggested in my first post - the hairpin NAT is only necessary when the LAN client is in the same subnet like the server, because only in that case a direct path bypassing the router exists between the client and the server. If you place the server to a DMZ with its own subnet, packets between the client and the server will go through the router in both directions. So the only thing to do will be to make the dst-nat rule, which translates packets towards pub.lic.ip.addr:port to a pri.va.te.ip:port, handle also packets coming from the LAN side.I have no problem opening up ports to the internet As long as it's to a DMZ. I don't want to open, lets say port 80, to a server on my LAN.
That's the reason I want a DMZ to put my webserver here so it's isolated from the rest of the LAN.
But I still want to be able to access www.example.com both from inside the LAN and from the internet without using split-brain DNS since the internal DMZ network wont be accessible from the LAN network anyway.
Re: Accessing external IP from LAN without hairpin NAT
Hmmm, I see you evaded my ip route question. Do not think I didnt notice. ;-P
Yes, now that the OP has provided clarity it is much simplified and as you stated the standard dstnat rule to handle outside queries will also work for inside queries (when using dyndns name/url) as was pointed out for the case of server subnet and lan subnet being different. Subnet to Subnet direct laniP from subnet A user to subnet B server will also work depending upon firewall rules (assumes different subnets that are not on same bridge or even better server is on a vlan).
So I am still waiting for the way to do this WITHOUT external users but still making use of the dyndns name/url.
Case: Users on subnet LAN A , server on VLAN
Admin wants users in subnet A to use myserver.org:2234 to reach server on VLAN but SINDY IS NOT ALLOWED to have a firewall rule allowing external users to access dstnat~~~
Now solve the puzzle... hint maybe use Sobs rule ??
Yes, now that the OP has provided clarity it is much simplified and as you stated the standard dstnat rule to handle outside queries will also work for inside queries (when using dyndns name/url) as was pointed out for the case of server subnet and lan subnet being different. Subnet to Subnet direct laniP from subnet A user to subnet B server will also work depending upon firewall rules (assumes different subnets that are not on same bridge or even better server is on a vlan).
So I am still waiting for the way to do this WITHOUT external users but still making use of the dyndns name/url.
Case: Users on subnet LAN A , server on VLAN
Admin wants users in subnet A to use myserver.org:2234 to reach server on VLAN but SINDY IS NOT ALLOWED to have a firewall rule allowing external users to access dstnat~~~
Now solve the puzzle... hint maybe use Sobs rule ??
Re: Accessing external IP from LAN without hairpin NAT
@anav, you're turning the straight & plain topic into a spaghetti plate.
/ip route rule is an instrument from the policy routing repertoir, where you need to use a specific set of routes for some devices, depending on the src-address or in-interface (or even more factors if you add mangle rules to the mix). There is no way to use it here, especially because when it comes to destination IP addresses which are up on the router itself, no policy routing is possible, and here the public IP is up on the router itself.
Another thing would be if the ISP was routing packets for another public IP to this router, but that address wasn't up on any of the routers' interfaces; in this case, you could use policy routing to access it. But even in such case, the hairpin NAT would be required if the client and the server were in the same subnet.
As for the filter rules... if you want to restrict dst-nated connections using e.g. a src-address(-list), you can make the action=dst-nat rule in /ip firewall nat match regardless the source, and then add the src-address-list matching to the action=accept (or drop) rule in /ip firewall filter for the already translated dst-address and dst-port. Or you can use a single simple common rule action=accept connection-nat-state=dstnat in /ip firewall filter (if the default is "drop the rest" of course) for any and all dst-nat'ed traffic, and place the src-address(-list) matching to the action=dst-nat rules. So what does not come from the right source does not get dst-nat'ed, and hence that filter rule doesn't accept it. So by outsourcing the filtering functionality from the filter table to the nat one, you can integrate two functions into a single rule. For a single dst-nated port it makes little difference, for multiple ones this integration makes the configuration simpler (albeit less systematic).
/ip route rule is an instrument from the policy routing repertoir, where you need to use a specific set of routes for some devices, depending on the src-address or in-interface (or even more factors if you add mangle rules to the mix). There is no way to use it here, especially because when it comes to destination IP addresses which are up on the router itself, no policy routing is possible, and here the public IP is up on the router itself.
Another thing would be if the ISP was routing packets for another public IP to this router, but that address wasn't up on any of the routers' interfaces; in this case, you could use policy routing to access it. But even in such case, the hairpin NAT would be required if the client and the server were in the same subnet.
As for the filter rules... if you want to restrict dst-nated connections using e.g. a src-address(-list), you can make the action=dst-nat rule in /ip firewall nat match regardless the source, and then add the src-address-list matching to the action=accept (or drop) rule in /ip firewall filter for the already translated dst-address and dst-port. Or you can use a single simple common rule action=accept connection-nat-state=dstnat in /ip firewall filter (if the default is "drop the rest" of course) for any and all dst-nat'ed traffic, and place the src-address(-list) matching to the action=dst-nat rules. So what does not come from the right source does not get dst-nat'ed, and hence that filter rule doesn't accept it. So by outsourcing the filtering functionality from the filter table to the nat one, you can integrate two functions into a single rule. For a single dst-nated port it makes little difference, for multiple ones this integration makes the configuration simpler (albeit less systematic).
Re: Accessing external IP from LAN without hairpin NAT
No worries, dont want to complicate matters, if there is not an easy route rule at play here, I will drop the subject...............
Re: Accessing external IP from LAN without hairpin NAT
So essentially if I don't have the server in the same bridge as the LAN and keep them on different subnets I will be able to use the public IP of the server from the LAN?
So in my mind it would be something like this:
RB3011 (no bridging):
eth1 -> ISP (IP for LAN)
eth2 -> ISP (IP for DMZ)
eth3 -> DMZ (internal: 10.0.0.0/24 external: aaa.bbb.ccc.ddd)
eth4 -> to CRS326 (switch)
CRS326:
eth1-24 -> bridge (internal: 192.168.0.0/24 external: eee.fff.ggg.hhh)
Everything on my LAN is connected to the CRS326 and the server is connected to my RB3011 on eth3
So in my mind it would be something like this:
RB3011 (no bridging):
eth1 -> ISP (IP for LAN)
eth2 -> ISP (IP for DMZ)
eth3 -> DMZ (internal: 10.0.0.0/24 external: aaa.bbb.ccc.ddd)
eth4 -> to CRS326 (switch)
CRS326:
eth1-24 -> bridge (internal: 192.168.0.0/24 external: eee.fff.ggg.hhh)
Everything on my LAN is connected to the CRS326 and the server is connected to my RB3011 on eth3
Re: Accessing external IP from LAN without hairpin NAT
Correct, but same/different bridge is not actually relevant, only different subnets are necessary. You can have multiple subnets on the same bridge/in the same VLAN. It is not a good habit but sometimes you have no choice.So essentially if I don't have the server in the same bridge as the LAN and keep them on different subnets I will be able to use the public IP of the server from the LAN?
In your suggested setup where the server subnet is only attached to ether3 of the 3011, all fine. Just check that the action=dst-nat rule forwarding traffic to the server also matches on packets coming in via ether4.
Re: Accessing external IP from LAN without hairpin NAT
Awesome. Thank you very much for your help!Correct, but same/different bridge is not actually relevant, only different subnets are necessary. You can have multiple subnets on the same bridge/in the same VLAN. It is not a good habit but sometimes you have no choice.So essentially if I don't have the server in the same bridge as the LAN and keep them on different subnets I will be able to use the public IP of the server from the LAN?
In your suggested setup where the server subnet is only attached to ether3 of the 3011, all fine. Just check that the action=dst-nat rule forwarding traffic to the server also matches on packets coming in via ether4.
I will try this out in the weekend if I have some time over
Who is online
Users browsing this forum: No registered users and 84 guests