- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thx for your answer, i try to search with keyword hairpin in forums
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this really a "bug" though or is it just that the FortiGate follows RFC exactly.
Mike Pruett
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
