SSL VPN Listens on all Interfaces???

Hey Chris,

I followed up with our team and I would like to perform further investigation regarding your SSL VPN and WAF conflict. Please raise a support case and PM me with your case number.

Thanks!

Any info on how this is going?

We were finishing the configuration of XG when I found out we cannot have the same port for WAF and SSL VPN like you can do in UTM! Not sure what to do now, throw away months of work or what really...

I believe allowing to select the interface to listen in OpenVPN, like you can do in UTM, would solve it. I don't know how XG got into production without this, port 443 can't be used for anything.

Any info on how this is going?

We were finishing the configuration of XG when I found out we cannot have the same port for WAF and SSL VPN like you can do in UTM! Not sure what to do now, throw away months of work or what really...

I believe allowing to select the interface to listen in OpenVPN, like you can do in UTM, would solve it. I don't know how XG got into production without this, port 443 can't be used for anything.

Same problem here.

Since SSL VPN listens on all interfaces, it blocks the designated port for all other services e.g. WAF.

this literately  makes it impossible to use 443 for most deployments.

Please add the possibility to limit SSLVPN to a particular interface or alias interface!

Hello

Setting up SSL VPN and a WAF. Both using port 443 and ran into this issue.

Has there been any change to be able to do this or even work around? Other then move the VPN or WAF to different port.

Am running SFOS 17.5.3 MR-3

Hello SPY3,

No, there is no workaround for your requirement.

Is there any ETA on a fix or workaround?

We are currently waiting for this to happen to migrate to XG.

WAF must be on 443 to avoid connection problems from restricted networks (companies, hotels, airports...) but VPN should use that port aswell for the same reasons. I think this should be a priority.

Hello ZLogistics,

We do not have an ETA at the moment on this implementation. We do have a feature request for the same and would encourage you to vote on this requirement.

As a workaround, i would suggest to talk to somebody regarding some small appliance with a NAT enabled.

Resolved all my blocker project regarding this feature with a simple second appliance, which "Re-NAT" the Traffic back to XG to another port. 

Thanks for the idea. I already thought of that but it's overkill in my opinion. Since this is possible with UTM and not XG, we will keep UTM until this is implemented on XG.

One customer used a Raspberry Pi for this rewrite. 

So it is up to you. 

I'm a huge fan of the Pi, but we can't rely everyone's access to the company network on a Raspberry Pi. Nice approach though.

Did this Issue change yet?