VPN traffic via NAT rules from WAN -> My Firewall -> Second Firewall
WENYEngineering
Newbie ✭
Hello,
We have a provider that needs to establish a VPN connection, through our firewall, to a cloud provider. Behind our Firewall is a Palo Alto that has a VPN Policy with a source IP of one of our WAN IP's, a destination IP of the cloud provider, and a shared secret. We provided an available LAN IP for their Mellanox switch. They gave me "firewall instructions" to allow different types of traffic. It looks something like this:
Palo Alto (OUR public IP) -> OUR LAN IP -> Our Sonicwall NATS that LAN IP back to the same Public IP used on the Palo Alto VPN Policy Source -> Cloud provider IP
The NAT rules for this VPN are for ICMP, TCP 500, UDP 500, TCP 3978, PING and IPSEC. In Packet Monitor I see very few "forwarded" packets from the LAN IP to the Cloud IP. I'm not sure if I've checked all the correct boxes. Do I need to set the Cloud IP's address objects as a zone vpn or is host okay? I only have NAT and Routing rules, do I need access rules too?
Thank you in advance
Answers
To answer the questions:
The Cloud Providers IP address object should be in the Zone in which it exists (i.e. it's on the Sonicwall's WAN).
What you are essentially doing is a port forward, so you'll need Access Rules too. See :https://www.sonicwall.com/support/knowledge-base/how-can-i-enable-port-forwarding-and-allow-access-to-a-server-through-the-sonicwall/170503477349850/
A suggestion: If the provider that requires the VPN tunnel allows it, just separate their equipment off the business network and setup the VPN tunnel on the Sonicwall. If the provider requires their own firewall put their Palo out on the 'net, not behind your firewall.
Hi TKWITS,
Thank you for taking the time to reply to me. The Cloud Provider's IP's (there are 6 of them) are in the WAN Zone and are grouped together as an "Address Group".
I have two access rules; a LAN to WAN, and a WAN to LAN. The LAN to WAN is Source (LAN IP) and Destination (Cloud Provider IP's) with the requested services (UDP 500 seems most important here). Of course it's opposite for WAN to LAN.
I'm familiar with our Sonicwall and navigating it, but incorporating a second Firewall is a first for me. I do agree that separating their equipment makes way more sense and would be easier. I'm not sure how they would take to reconfiguring their network design; that's a different rabbit hole.
I did a Packet Monitor and I see packets now; not a lot (there's no active connection so I would assume there wouldn't be a lot) but I see them. Source IP is Cloud IP with Source Port 500.
Ingress X0*(i) Egress X12 Source (LAN) Destination (Cloud Provider) Packet UDP Ports 500,500 Status FORWARDED
Ingress -- Egress X12* Source (WAN IP) Destination (Cloud Provider) Packet UDP Ports 58869,500 Status FORWARDED
Is the "FORWARDED" packets a good sign that the traffic from the Palo Alto is at least successfully leaving our Sonicwall?
Generally you want to see packets 'forwarded'. But I cannot tell from your description if the palo traffic is what is leaving.
Post sanitized screenshots of the packet details from the packet monitor, and provide a better description of what IP the Palo is using.
In image 1.JPG, Packet Detail is highlighted for packet #1. In image 2.JPG, Packet Detail is highlighted for packet #2. The Palo Alto VPN Policy is set to a source Public IP of 72.xx.xx.xxx and destination Public IP of 137.xx.xxx.xx. We feed our LAN into their switch and gave them the LAN IP of 192.xxx.x.xxx. I believe they are doing a NAT on their Palo Alto from/to the 72. to the 192.
The assigned Public IP of 72.xx.xx.xxx is also an available IP in our ISP range of IP's and is part of our X12 interface. X0 is our LAN. The idea I guess, is to NAT 72 to 192 from the Palo, then NAT 192 back to 72 in our Sonicwall out to the 137.
At one point I saw dropped packets due to "IP Spoof" but that has since been rectified. The claim from the "Cloud" side was they didn't see any traffic from us. Our ISP confirmed they don't block any ports on their modem. A TraceRoute from the Sonicwall doesn't show a final hop of the 137, but can ping it from the X12. Also, I do see that final hop when doing a tracert on my workstation.
It's not likely the Palo is NATing outbound traffic to the 72.x.x.x address for two reasons: You didnt give them the 72.x.x.x address for their WAN interface; thats not how routing works.
What IP did you tell them to use on the Palo WAN interface? Show your Sonicwall NAT rules for the Palo traffic.
So I looked at the physical wiring; it looks like our LAN is plugged straight into Port 7 of their Palo Alto firewall. They assigned that port 7 as the 192.x.x.x address.
I gave them one of our available Public IP's as the Cloud provider needs to know how to talk to our Sonicwall. It was not in their provided instructions of what they would do with it; I assumed it was to communicate to the Cloud provider.
Their VPN Policy configuration was done by them; I didn't suggest that Public IP for their Palo Alto, they configured that on their own. I'm assuming their doing something in their Palo Alto between their VPN Policy configuration with our Public IP as source; and Port 7 that's assigned our LAN IP of 192.x.x.x we gave them. Again I do see packets from 192. to 72. to 137.
I attached some of the diagram they provided as well for reference.
I wouldn't NAT only the specified VPN traffic, NAT any traffic from the Palo to anything on the internet with their assigned public IP. Otherwise you'll end up missing something. Same on inbound.
Show your Sonicwall access rules for the Palo.
Do you know what else is behind the Palo?
Double NATd VPNs can be a pain, and that is what you are dealing with here. If they can, have the Palo people use IKEv1 Aggressive Mode or IKEv2 for the tunnel with the cloud side gateway set to 0.0.0.0 and rely on 3rd party certs or other security, rather than IP. I've had to do this on double NATd VPNs I control.
It's possible the Sonicwall is seeing the return VPN traffic as something it should be responding to and is consuming it rather than forwarding it to the Palo.
There is a Mellanox switch behind the Palo, and all their own gear (2 video streaming servers for the major TV network and 2 IRD's for inputting satellite RF).
Also, just finally received communication back that the Cloud team sees 0 traffic from us even though I see those Forwarded packets. If they're seeing 0 traffic from us, then I would expect that would be why I see 0 traffic back to me. I was also considering wireshark in random places to deep dive further.
I'll try adjusting the NAT rules to see what happens per your advice.
I'll also suggest to them the above. I hate feeling so close to fixing something but am also learning a lot.
Open up those access rules to 'Any' traffic.
Have you had any progress?
From your last reply I did set the Access Rules to Any. I noticed in Log Monitor I'm seeing "IP Spoof" errors coming from our LAN 192.x.x.x (this is the IP they assigned to their Palo Alto interface 7) to the 137.x.x.x address (Cloud provider outside our firewall). I'm not sure if this "spoof" is due to their VPN policy that uses one of our Public IP's as their source. Would the spoof be due to their VPN policy with our public IP, NAT'ng to one of our LAN IP's, then that traffic trying to traverse our Sonicwall?