Yes, I know, it’s there everywhere on the net, but I still need to put it in shortest format as a reference for myself and “maybe” others.
The scenario is a Paloalto NGFW with two interfaces, one connected to public and one connected to DMZ or internal.
Under the “Security” policies, source zone is always the external one, and source addresses are either wildcard/country/specific; on destination, however, the zone will be DMZ but the address will be the external IP address on which you’re expecting to receive the traffic. Services running on the firewall itself are exceptions as the destination zone would be external as well.
Under the “NAT” policies it is simple. Both source and destination zones would be the external one. As for the address, it will be same as in security policy, with proper destination translation.
Having fun with BYOL model on cloud service provider while trying to run your own copy of Paloalto VM NGFW? And get all interfaces (except the management showing down state?
Login to the console and have a look at the “show interface all” command’s output, if you see the MAC address of one or more of the NICs as BA:DB:AD:BA:DB:AD most likely you’re having an issue with DPDK and you need to turn it off by running the command “set system setting dpdk-pkt-io off“.
Seems the method of using certificate-based connection won’t work with non-Sophos firewall.
I had to switch to shared-phrase in order to make it work.
Not sure if that problem is due to old firmware/device on the other side or is it compliance issue.
However, I had to go on the VPN settings on both firewalls and make sure all settings at both sides are exactly the same.
Finally, I decided to switch back to pre-shared key instead of the certificate-based authentication between the two appliances.
The moment I set the key on the initiator, the tunle immediatly came up.
Yep, no much result on the web about this subject.
I don’t know what the cause, nor why Sophos didn’t take it seriously.
Anyway, if you’ve downloaded version 16 of Sophos XG virtual appliance for KVM and you got the nice error message of
firstboot failed: swapon /dev/swap
But, if you know and sure you’ve done everything right and as per Sophos documents, then most likely you have the same issue we run through.
For some unclear reason we were able to solve this by having the Hyper-V version of the same appliance and run it on KVM platform
Our team members are testing it now on OpenStack with our service provider to make sure of the compliance.