Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
tronton_team
New Contributor

(ask) Cannot access ip public from internal network

hello, i want to ask, i have ip public 2.2.2.2 that mapped with virtual IP to internal network 192.168.10.5 to access CCTV,

if iam outside network and use mobile data with my phone i can access cctv with ip 2.2.2.2, but if i use my internal network and access cctv with my public ip 2.2.2.2 cannot access cctv, how to solve that problem? sory for my bad english.

6 REPLIES 6
Nils
Contributor II

Try to create a rule/policy from Internal to Internal with the VIP object as destination.

Not sure if this is working but give it a try.

ede_pfau
Esteemed Contributor III

The policy is necessary, and the VIP must be connected to the "any" interface, not "wan". Please search the forums for "hairpin", this problem has been posted several times (with solutions).


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
tronton_team

thx for your answer, i try to search with keyword hairpin in forums

MikePruett

Is this really a "bug" though or is it just that the FortiGate follows RFC exactly.

Mike Pruett Fortinet GURU | Fortinet Training Videos
Nils

MikePruett wrote:

Is this really a "bug" though or is it just that the FortiGate follows RFC exactly.

It's not a bug, it just how the firewall is working.

Same problem with Cisco ASA for example.

If not don't allow the traffic on a interface, the firewall will drop the traffic.

ede_pfau
Esteemed Contributor III

Never thought of this as being a bug. "Life of a packet" says NAT comes first, then policy. So essentially you make an 'internal' to 'internal' connection. This is reflected in the policy.

 

The only tricky (as in: hidden) part is that the VIP needs to be unbound, i.e. bound to 'any'. This is an implementation detail as the VIP triggers arp proxying as well as address translation. Specifying the VIP's interface restricts the arp action to what is necessary, releaving the CPU. In this case, it needs to be 'listen to all traffic' though.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Labels
Top Kudoed Authors