Incomplete sessions for NATTING/Access to different site DMZ

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Incomplete sessions for NATTING/Access to different site DMZ

L1 Bithead

Hi All,

I am having a complex and tricky setup that require NATTING and host web server in different network/site DMZ, I know it is not best practice but hope you can help:

Here is topology:

Site A zones: Trust, Untrust and DMZ with their own public IP and web servers

Site B zones: Trust, Untrust and DMZ with their own public IP and web servers

In case site B internet is down and all of the web servers in Site B is unreachable, but internal connection from Site A and Side B is up, I want to re-direct hosting Site B web server in Site A. For reasons, we cannot move the Site B server to site A.


This is what I did:

-Site A PAN Firewall: NATTING from Site A (public IP) to Site B – DMZ web server. Then allow web services access from UNTRUST

-Site B PAN firewall: Allow web services access rule to Site B DMZ web server from both TRUST and UNTRUST


Connection will be from public (UNTRUST) hit the site A public IP address (NATTING to Site B web server), then travel cross internal connection to web server in Site B DMZ. Problem is Site B firewall confused this connection from TRUST or UNTRUST, so it keeps drop and aged-out the sessions. Internal connection from SITE A to SITE B for sure is TRUST.


I know the traffic is allowed on both SiteA/B firewall, is there any better way for this scenario? Or I miss anything else.

Thanks and Regards,

Long Nguyen

2 REPLIES 2

Cyber Elite
Cyber Elite

@infoit,

 

First, as your traffic from public (UNTRUST) will hit the site A public IP address (NATTING to Site B web server), then travel cross internal connection to web server in Site B DMZ so traffic towards SITE-B firewall will come up with source zone as trust as it is traveling via your internal interface (trust) connected between both firewalls.

 

Now the source will be public IP so you need to check routing for those source public IP addresses on SITE-B Firewall. Most of the times on the firewalls, default route is set to external interface. Due to this route, the response from DMZ server at Site-B will go towards external interface (as it will match default route).

 

I think, this is creating problems. I can suggest few pointers -

 

1. If you know the source public IP addresses/networks, make proper routing on SITE-B firewall so response will go through proper path. Not sure if you would have these details as most of the times we are not aware of all public source IP addresses unless whitelisting is done.

 

2. You can NAT source IP address of traffic initiator on SITE-A Firewall. So if you NAT source public IP with any internal IP address (can be trust and known to SITE-B). So all the request will come from single source on SITE-B Firewall.  But with this, you won't be able to see actual client IP address om DMZ end.

M

Thank you Sutare for your ideas.

For option 1: I have a list of site A Public IP, so  of I am thinking about setup a new route on Site B to re-route the traffic hitting Site B DMZ and return back to Site A public IP

Option 2: I already setup NAT source Site A IP with internal IP address on Site B already, but still fail. Routing work but I need to check if PAN inspect the traffic and drop the connection as spoofing TRUST connection from untrust.

  • 2324 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!