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

[Resolved]External IP Destination Redirect

Good morning, I have an external site with an access device (badge reader) behind a fortigate firewall. This device was setup to an old external IP address for our corporate location that we no longer have access to. This device can be changed remotely once it is talking to the controller at corporate, but otherwise someone would have to go to the location to make the changes. Is there a way on the fortigate (80CM 4.0MR2P1) to do an internal to external VIP (or anything else that would let me rewrite the external address as it goes through the fortigate)? Has anyone done this before or know of a guide on how to achieve this? An example is the internal device is trying to contact out to 1.2.3.4 from an internal ip of 10.1.1.10 and I would like the fortigate to change the destination to 9.8.7.6. Thanks, Jeff
6 REPLIES 6
ede_pfau
SuperUser
SuperUser

Hi, to achieve a destination NAT you define a VIP like this: Firewall>Virtual IP>Virtual IP Create New Name: readerVIP Ext. Interface: internal Type: Static NAT Ext. IP: <old IP> Mapped IP: <new IP> no Port Forwarding In Firewall>Policy>Policy, create a new policy for outgoing traffic (just for this one device): source IF: internal source IP: <reader' s internal IP> dest IF: wan1 dest IP: readerVIP service: ALL NAT: enable (!) action: ACCEPT Be sure to place this policy above others that affect traffic from inside to outside.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Not applicable

Thanks for that walkthrough ede! I have the following config for the FW Policy and it' s at the top for internal to wan1 (Sanitized to use above examble. 5.4.3.2 is being added as the external VIP for internal 10.1.1.10): Sweet123-OM-FW80~ # show firewall policy 38 config firewall policy edit 38 set srcintf " Internal" set dstintf " wan1" set srcaddr " iplink_test" set dstaddr " Old_External_NAT" set action accept set schedule " always" set service " ANY" set nat enable next end config firewall vip edit " Old_External_NAT" set extip 1.2.3.4 set extintf " internal2" set mappedip 9.8.7.6 next end config firewall address edit " iplink_test" set associated-interface " Internal" set subnet 10.1.1.10 255.255.255.255 next end config firewall vip edit " Substation 2 ADT Access" set extip 5.4.3.2 set extintf " wan1" set mappedip 10.1.1.10 next end But, i' m not showing that it' s NATing like it is supposed to (sanitized): 243.470556 internal2 in 10.1.1.10.##### -> 1.2.3.4.#####: udp 41 243.470627 wan1 out 10.1.1.10.##### -> 9.8.7.6.####: udp 41 Does this look like a bug in the firewall engine or a config error on my part?
Not applicable

One other code snippet is that it looks like the external destination NAT is working properly: id=36870 trace_id=7 func=resolve_ip_tuple_fast line=3371 msg=" vd-root received a packet(proto=17, 10.1.1.10:#####->1.2.3.4:#####) from internal2." id=36870 trace_id=7 func=resolve_ip_tuple_fast line=3405 msg=" Find an existing session, id-0371b098, original direction" id=36870 trace_id=7 func=ipv4_fast_cb line=56 msg=" enter fast path" id=36870 trace_id=7 func=ip_session_run_all_tuple line=4362 msg=" DNAT 1.2.3.4:#####->9.8.7.6:#####"
ede_pfau
SuperUser
SuperUser

I translate from your config: 1) when any host from inside addresses 1.2.3.4, the external destination IP is changed to 9.8.7.6. 2) when any host from outside addresses 5.4.3.2 the internal destination IP is changed to 10.1.1.10 3) outgoing policy only allows 10.1.1.10 to use destination NAT defined in 1) ...this looks OK to me. Sure you have a second policy for wan->internal using the second VIP ( 2) above). I' m a bit puzzled about ' Internal' and ' internal2' interface names - ? Actually, to reach the internal device you' d only need an inbound VIP (like 2) ) but then again maybe your device is clamped to only answer to 1.2.3.4. The proof is in the pudding - does it work then?
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Not applicable

Thanks for your help Ede! I found there was a stuck open session using the old policy. Once I killed that it started working great.
ede_pfau
SuperUser
SuperUser

I' m glad it' s working now, my pleasure to help you.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors