topic Re: u-turn - why? in General Topics

u-turn - why?

MarcinR — Wed, 04 Apr 2018 15:39:30 GMT

Hello,

i'm moving complex configuration from Juniper's ISG2000 (ScreenOS) to PA-5220 and i faced a problem with internal servers (in DMZ zone) which should be available for everyone (including our own employees) on public IP addresses.

On ScreenOS it was simple:

Created MIP/VIP object (server-public-ip -> server-internal-ip)

1st rule from trust any to untrust any permit with source NAT enabled

2nd rule from untrust any to dmz mip/vip-object permit

When i started moving this setup to PA i read about something like U-Turn and i got shocked why something like that is necessary: to setup special NAT for EVERY internal vlan/subinterface, which both translates source and destination address... Imagine you've got 100 vlans/subinterfaces and 50 servers and you have to set u-turn for all of them (or am i missing something?)...

So i setup configuration like this and it WORKS. I'm PA newbie so i would like to hear comments what's wrong with this approach since u-turn is recommended, not this solution.

Situation:

DMZ interface: 172.18.0.254/24

Server internal: 172.18.0.82

Server external: 200.200.200.200

Untrust interface: 200.200.200.254/24

Workstation in Trust: 10.0.0.1

Interface in Trust: 10.0.0.254/24

NAT1:

source zone: DMZ

destination zone: Untrust

source address: 172.18.0.82

destination address: any

source translation: static-ip 200.200.200.200 bidirectional: yes

NAT2 (general)

source zone: Trust

destination zone: Untrust

source address: any

destination address: any

source translation: dynamic-ip-and-port 200.200.200.199

security policy1:

source zone: any

source address: any

destination zone: dmz

destination address: 200.200.200.200

service: any

action: allow

security policy2:

source zone: any

source address: any

destination zone: Untrust

destination address: 200.200.200.200

service: any

action: allow

security policy3 (general):

source zone: Trust

source address: 10.0.0.0/24

destination zone: Untrust

destination address: any

service: any

action: allow

That's it. Workstation in Trust zone (eg. 10.0.0.1) access server on IP address 200.200.200.200.

Moreover, it doesn't matter how many internal zones/subinterfaces(vlans) you have, all of them will have access to server in DMZ using it's public IP address. There's no need to add additional NAT for u-turns.

Ofcourse it's also possible for one-way destination NAT:

source zone: any

destination zone: untrust

source address: any

destination address: 200.200.200.200

destination translation: 172.18.0.82

What's wrong with this approach?

Regards,

Marcin

Re: u-turn - why?

dstjames — Wed, 04 Apr 2018 16:52:18 GMT

I had to setup u-turn for webmail access on our guest wifi network. The reason is because they are segregated from our internal network they use public DNS to go out and query the IP and get the public IP for e-mail rather than the internal. Then when the client goes out to this IP the internet would send it right back in the same connection and come back in. By default routers do not like to receive traffic that they send out the same interface. So the U-turn basically just tells the DNS query to use the DMZ IP rather than the public IP to get to this service.

This fixed the issue for us.

Re: u-turn - why?

reaper — Thu, 05 Apr 2018 07:44:56 GMT

hi @MarcinR

U-turn is only required when the server is on the same subnet as the client because else you'd get asymmetric routing (client sends syn to firewall, firewall applies NAT and forwards to server, server identifies source as same subnet and sends directly (see https://youtu.be/Bdbn1pbe74o at about 1:00)

If the server is in a differend zone/subnet, this will be limited to other servers in the same zone/subnet trying to use the public IP, clients in the lan would not need source translation (u-turn), only due care that the destination nat policy for the server's public IP is above the generic outbound nat rule

tl:dr: u-turn is only required if client and server are in the same subnet/zone, not if the server is in dmz (just make sure your nat rules are in the appropriate order)

Re: u-turn - why?

MarcinR — Thu, 05 Apr 2018 09:32:04 GMT

Thank you @reaper for your answer. If we say about hosts in the same net - that is clear to me. U-turn is required.

The problem is that tutorials say that u-turn is required BETWEEN zones/interfaces, eg.:

"To enable clients on the internal network to access the public web server in the DMZ zone, we will need to

configure a NAT rule that redirects the packet from the external network, where the original routing table

lookup will determine it should go based on the destination address of 203.0.113.11 within the packet, to

the actual address of the web server on the DMZ network of 10.1.1.11. To do this you must create a NAT

rule from the trust zone (where the source address in the packet is) to the untrust zone (where the original

destination address is) to translate the destination address to an address in the DMZ zone."

https://live.paloaltonetworks.com/t5/Learning-Articles/DotW-U-Turn-NAT-Issue/ta-p/53115

or https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-U-Turn-NAT/ta-p/61889 (second example: This is an example of the U-turn NAT and Security for Hosts and Web Servers in a Different Zone).

Can you please explain that?

Re: u-turn - why?

reaper — Thu, 05 Apr 2018 09:53:36 GMT

Hi @MarcinR

I think there's confusion about the 'concept' of u-turn/hairpin nat (packet goes out to public ip, then comes back in to private ip) and the full source+destination translation configuration of u-turn

In a configuration with strict policy (not relying on the implied policies created by bi-directional rules) you do need to create a specific NAT policy to allow internal clients to reach internal servers on their public IP

in strict policy:

untrust to untrust <publicIP> to <dmzIP>

dmz to untrust <dmzIP> to <publicIP>

trust to untrust <lanIP> to <firewallIP>

you need to add a 'trust to untrust <publicIP> to <dmzIP>' (u-turn) above the last policy to allow internal hosts to reach the server on it's public IP (else you will use the hide-nat policy and start a LAND attack)

in 'loose' policy

dmz to untrust <dmzIP> to <publicIP> bi-directional

*implied policy* any to untrust <publicIP> to <dmzIP>

dmz to untrust <dmzIP> to <publicIP>

trust to untrust <lanIP> to <firewallIP>

so no additional policy is required

eg:

"bidir; index: 5" {
        nat-type ipv4;
        from internal;
        source 192.168.0.21;
        to external;
        to-interface  ;
        destination any;
        service 0:any/any/any;
        translate-to "src: 198.51.100.21 (static-ip) (pool idx: 6)";
        terminal no;
}

"bidir; index: 6" {       <- this implied policy is autocreated by checking the 
        nat-type ipv4;       bi-directional toggle and takes care of u-turn sessions
        from any;
        source any;
        to external;
        to-interface  ;
        destination 198.51.100.21;
        service 0:any/any/any;
        translate-to "dst: 192.168.0.21";
        terminal no;
}

hope this makes more sense

Re: u-turn - why?

fjwcash — Mon, 16 Apr 2018 17:51:55 GMT

You're confusing double-NAT with U-Turn NAT.

Double-NAT means you translate the source IP address *and* the destination IP addres. This is needed for crossing zones and subnets where you don't have direct routing for private IP addresses enabled.

Client has 192.168.0.0/24 subnet. Server has 10.0.0.2 IP. You have public IP 1.2.3.4 for your outgoing client NAT for Internet access. You have 1.2.3.5 for your server's public IP.

So you need to create a NAT Policy that takes traffic from 192.168.0.0/24 to 1.2.3.5 and translates the source IP to 1.2.3.4. *AND*, in the same policy, also translates the destination IP to 10.10.10.2.

And there's a few other NAT/Security Policies needed to make that work. But the above double-NAT rule is the important one.

This way, the clients only every connect to the public IP, and the server only ever sees the public IP of the clients, and everything is handled nicely through the normal routing tables.

U-Turn NAT also means you translate the source IP and the destination IP, but is used for sending traffic back to the source zone and to the same subnet as the client.

Client has 192.168.0.0/24 subnet. Server has 192.168.0.2 IP. You have public IP 1.2.3.4 for your outgoing client NAT for Internet access. You have 1.2.3.5 for your server's public IP.

So you need to create a NAT policy that takes traffic from 192.168.0.0/24 to 1.2.3.5 and translatest the source IP to 1.2.3.4 *AND* translates the destination IP to 192.168.0.2.

And there's a few other NAT/Security Policies needed to make the traffic work.

This way, the clients only ever connect to the server's public IP, and the server only ever sees the public IP for the clients, and all the traffic is handled via the normal routing tables on the server.

However, a much nicer solution to the U-Turn NAT is split-DNS, or DNS Views (in BIND). When a client on the private network does a DNS query for my.server.com, it gets the private IP of the server returned. If a device on the Internet does a DNS query for my.server.com, it gets the public IP of the server returned. That way, local traffic never goes through the firewall at all.

Re: u-turn - why?

katerinap — Tue, 16 Oct 2018 02:35:34 GMT

I have a totally similar setup. The issue is that Palo Alto cannot NAT both the source and the destination by matching different rules, so it uses one of the rule you configured. It probably translates the destination (that's how it gets to the server) and it leaves the source (10.0.0.1) as is. Does your server have a route to send the traffic for 10.0.0.1 back to the firewall? If so, that would work. In my case, the server wouldn't know to get back to the internal address of the source (they are on different VRFs).

Can you look at your packets and see what happens? I'm curious. For me, the source doesn't get NATed unfortunately (I have a rule like the NAT2 (general) you posted).

Re: u-turn - why?

MarcinR — Tue, 16 Oct 2018 08:02:46 GMT

Source IPs aren't NATed (servers on public IPs see our internal IPs). For us it isn't a big problem because servers can send packets back to internal IPs using default gateway.

If you need a setup where your servers on public IPs see internal clients but on your public (NAted) IP then probably you need to create separate rule for each server where you do both NATs (source and destination). And that is a real pain if you have many servers.

Re: u-turn - why?

katerinap — Tue, 16 Oct 2018 16:50:53 GMT

Thanks for your reply MarcinR. Yes, this is the issue I am facing right now and I thought there would be a way to get around it but apparently the only way to make this communication work is create a source and destination translation NAT for every source subnet and destination server. Not excited 😞

Re: u-turn - why?

reaper — Wed, 17 Oct 2018 11:35:28 GMT

hi @katerinap

You could also move your servers into their own zone (like a dmz), this way you'd only need 1 NAT rule for everything internal and 1 for everything external

trust to untrust any to publicIP nosourceNAT destinationNAT

untrust to untrust any to publicIP nosourceNAT destinationNAT

Uturn NAT is only required when client and server are in the same broadcast domain causing reply packets from the server to not be sent back to the firewall but directly to the client instead. This is resolved by adding sourceNAT for the internal IP of the firewall so return packets are sent to the firewall

trust to untrust any to publicIP sourceNATfwIP destinationNAT

another solution is to populate internal DNS servers with an internal IP for the servers FQDN so there's no longer a need for NAT