Comments

  • If you have a public range, you could assign it to a single VLAN (though you may need to work out a new non-overlapping range from the ISP for the Firebox external IP), then perhaps have customer NAT routers on that VLAN, each with a different IP. Their routers' external interfaces will all be on the same broadcast domain…
  • If the API traffic is going through a packet filter, it should be no problem. There is a very slim chance a subscription service is interfering, but extremely unlikely if the traffic is all TLS encrypted. If using HTTPS proxy, could be a problem regardless if the certificate for content inspection is installed. I've seen…
  • It sounds like this could possibly be an ISP issue. Some ISP's, especially mobile carriers, block IPSec and SIP. Packet capture on the secondary WAN using TCPDump would be helpful to see what is happening with the ISAKMP and ESP traffic. https://www.watchguard.com/help/video-tutorials/TCP_Dump/index.html Arguments,…
  • The next thing I would do is verify that the inbound 60999 traffic is being forwarded to the PC. It sounds like you've seen allow logs that indicate it is. You could capture using the TCPDump utility on the firewall or capture from the PC itself with Wireshark. If the 60999 traffic can be confirmed to reach the PC, the…
  • If I'm understanding the current setup correctly, you have external static IP's NATted to client routers on internal VLANs, which use private addressing. It sounds like you want to switch to an arrangement where they have their own public range per VLAN. I think that's technically doable, assuming you have enough public…