- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
06-27-2022 04:20 AM
Greetings!
As title suggests, I'm trying to implement PBF to the specific destination network in Internet through a server residing in DMZ. There are three zones configured:
PBF rule matches source and destination IP networks (10.0.5.0/24 => 203.0.113.0/24) and works as intended. In traffic log I can see my requests being rerouted from Inside to DMZ and tcpdump on server surely shows connections from 10.0.5.0/24 network.
The problem occurs when server itself tries to reach to the actual destination network. Either NAT is not happening during forwarding or something else is discarding traffic in firewall. I can see retransmissions happening before the session is dropped.
Tried srcnat with unused IP from my BGP pool (routed from upstream to firewall which works in normal routing flow between zones) in both INSIDE to DMZ or DMZ to OUTSIDE flows. From Inside to DMZ flow it happens and I can see my internal network already NATted to public IP in server's tcpdump, but connection still fails.
From what I understand, in this scenario firewall sees traffic from 10.0.5.0/24 but sourced from DMZ zone. Could there be something like uRPF mechanism kicking in? There are no errors in traffic log either.
06-27-2022 06:41 AM
Hi @Flang3r ,
The main problem is that your Linux host in the DMZ is just forwarding the received packet. There are actually couple of reason this willl not work:
- As you correctly assume uRPF or anti-spoofing protection will drop the traffic when it sees that packet is ingresing on DMZ interface, while the source address is from the Inside zone.
- Return traffic will not be forwarded to DMZ, instead directly to Inside, which will cause the return traffic to have different egress interface and probably not match the session in the firewall session table.
You need to use source NAT on the Linux host, which will translate the original source IP of the host in the Inside zone, either to the Linux host DMZ IP, or any other available IP address in the DMZ network.
After that you will need proper NAT to translate that address to public one and also security rule for allowing the private IP in the DMZ network ( source zone DMZ) to internet.
06-27-2022 06:41 AM
Hi @Flang3r ,
The main problem is that your Linux host in the DMZ is just forwarding the received packet. There are actually couple of reason this willl not work:
- As you correctly assume uRPF or anti-spoofing protection will drop the traffic when it sees that packet is ingresing on DMZ interface, while the source address is from the Inside zone.
- Return traffic will not be forwarded to DMZ, instead directly to Inside, which will cause the return traffic to have different egress interface and probably not match the session in the firewall session table.
You need to use source NAT on the Linux host, which will translate the original source IP of the host in the Inside zone, either to the Linux host DMZ IP, or any other available IP address in the DMZ network.
After that you will need proper NAT to translate that address to public one and also security rule for allowing the private IP in the DMZ network ( source zone DMZ) to internet.
06-27-2022 06:50 AM
Thank you for the reply. That's exactly what I've ended up doing. MASQUERADE on the Linux server with its own IP for specific source networks (ingress via PBF) and then srcnat of that DMZ IP to Outside on PA. I can observe two sessions per flow, one to the server and another corresponding flow from the server.
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!