Onwave requests a feature request that would be extremely useful for NAT mode SFVPN deployments please – the facility to statically assign IP addresses to SFVPN tunnel interfaces rather than have them assigned via DHCP pool?
That would:
-immediately reduce the resources required on the box because DHCP would not be required.
-allow us to deterministically match customer traffic to the IP assigned.
An additional feature (desirable) would be the facility to Port Forward to SFVPN tunnel interface IPs.
HI,
This would be excellent also because it would allow everyone using the NAT mode feature to associate a customer site’s tunnel with an IP.
That means the customer traffic can be identified easily in a predetermined way. For example: That way you can use the IP to monitor the customer traffic knowing that the IP won’t change over time -like when the VPN reestablishes for any reason-, and if the customer has unsecured SMTP or DNS (or other) hosts that get compromised you can immediately identify where the offending traffic is originated.
Hi, we are still being hit by the problem of SFVPN in NAT mode with pool exhaustion because IP to SFVPN bindings are not being rebound with the SFVPN when the SFVPN for a site drops and reestablishes. If we could be allowed to create DCHP reservations for the SFVPN connected site it would solve this problem and it would be a huge advantage to have a deterministic IP for each SFVPN traffic.
Please!
