Hello,
I have a scenario where a Server A (IP x.x.x.x) on port 10 of FG 500D (5.2) is configured to send TCP and UDP traffic to Server B (IP y.y.y.y) on Port 11. Using static routes I am able to successfully test connectivity between Servers A and B (no static NAT for server B currently)
I want (but not sure how) to achieve the following,
- Intercept the incoming TCP / UDP stream from Server A
- change (or NAT) the source IP x.x.x.x of Server A to an IP (y.y.y.a) in the same subnet as Server B
- Manipulate the original packet destination address. I want the TCP stream to retain the destination as Server B (y.y.y.y) but send UDP traffic to a Server C (y.y.y.c) in the same network as Server B
So at the end I would expect Server B to receive TCP traffic from source IP a.a.a.a and Server C to receive UDP traffic from source a.a.a.a
I created an IP pool and applied a policy to perform the source NAT, and was able to see that the source IP is being change as the packet exits port 11. I still need assistance to change the destination of the packets.
All help is appreciated
Regards,
Moe Shea
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
hi,
and welcome to the forums.
Though I understand what your objective is I'd say you are going to use the wrong tool.
All that you want to do is route traffic to one of two destinations. The means for this in FortiOS is Policy routing. Regular routing only looks at the destination address; policy routing (PR) can match traffic additionally by source address, source port, destination port and QoS.
It cannot match the service directly though, but you can compensate for this by using the corresponding port numbers. E.g. HTTP would be tcp/80 and DNS udp/53. Knowing your traffic you would configure one PR to route port 80 to 'port1' and one PR to 'port2'.
If that doesn't work out for you you'd use NAT: source NAT is done by an IP pool, destination NAT by a VIP (virtual IP). Using both in a policy which is matching TCP traffic only, and one similar policy matching UDP should do the trick.
BTW, are you really still using v4.2?
hi,
and welcome to the forums.
Though I understand what your objective is I'd say you are going to use the wrong tool.
All that you want to do is route traffic to one of two destinations. The means for this in FortiOS is Policy routing. Regular routing only looks at the destination address; policy routing (PR) can match traffic additionally by source address, source port, destination port and QoS.
It cannot match the service directly though, but you can compensate for this by using the corresponding port numbers. E.g. HTTP would be tcp/80 and DNS udp/53. Knowing your traffic you would configure one PR to route port 80 to 'port1' and one PR to 'port2'.
If that doesn't work out for you you'd use NAT: source NAT is done by an IP pool, destination NAT by a VIP (virtual IP). Using both in a policy which is matching TCP traffic only, and one similar policy matching UDP should do the trick.
BTW, are you really still using v4.2?
Thank you Ede for the reply and it is great to post first time here. Actually I am using 5.2
Using policy routing, can it actually change the destination of the traffic, or it will only affect the path the traffic takes to reach its original destination? As you know the traffic in my case is destined to Server B. I want to change this to have only TCP going to Server B and UDP going to Server C.
For the NAT part, I have been able to change the source IP using IP pool, but now to change the destination IP, when creating the VIPs,
- for external IP addresses/Range, should this be the real IP address of Server A or its NATTED ip address from the IP pool config?
- for the mapped IP addresses/Range, should this be new VIPs or the real IP addresses for Servers B and C ?
Appreciate your feedback.
regards,
Moe Shea
hi,
you're right in assuming that PR only changes the path of traffic, not it's source or destination addresses. The routing part does not change any of the packet's data, neither the envelope nor the content. The only difference between regular routing and PR is that in the latter case you have more criteria to make a match.
Now for using a VIP: the 'external' address is the address you will use, the 'mapped to' address will be the address used. A VIP changes the destination address of a packet.
For example, you create a VIP on the WAN interface (to give you an example which is totally different from a VIP's obvious use). You configure
external interface: 'internal' (or 'lan' on small FGTs)
external address: '7.7.7.7'
mapped to interface: 'wan1'
mapped to address: '8.8.8.8' no (!) port mapping
Then, create a policy from 'lan' to 'wan1', source 'all', destination 'this_VIP', service 'ALL'. Enable NAT (because you're sending traffic from private network to WAN). Put this policy on top of your policy list.
Result: if you ping 7.7.7.7 you get an answer from Google DNS on 8.8.8.8.
C:\>ping 7.7.7.7
Ping wird ausgeführt für 7.7.7.7 mit 32 Bytes Daten:
Antwort von 7.7.7.7: Bytes=32 Zeit=81ms TTL=47
Antwort von 7.7.7.7: Bytes=32 Zeit=81ms TTL=47
Antwort von 7.7.7.7: Bytes=32 Zeit=78ms TTL=47
Antwort von 7.7.7.7: Bytes=32 Zeit=80ms TTL=47
Ping-Statistik für 7.7.7.7:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 78ms, Maximum = 81ms, Mittelwert = 80ms
C:\>tracert 7.7.7.7
Routenverfolgung zu 7.7.7.7 über maximal 30 Abschnitte
1 7 ms 5 ms 7 ms 7.7.7.7
2 47 ms 47 ms 47 ms 7.7.7.7
3 48 ms 47 ms 47 ms 7.7.7.7
4 520 ms 538 ms 337 ms 7.7.7.7
5 565 ms 426 ms * 7.7.7.7
6 * 391 ms 399 ms 7.7.7.7
7 271 ms 268 ms * 7.7.7.7
8 * * 567 ms 7.7.7.7
9 516 ms 482 ms 592 ms 7.7.7.7
10 409 ms * * 7.7.7.7
11 * * * Zeitüberschreitung der Anforderung.
12 * 337 ms * 7.7.7.7
13 601 ms * 456 ms 7.7.7.7
Ablaufverfolgung beendet.
You see that a VIP works both ways: if you open a session to a VIP the reply traffic will be re-substituted as well. In my example, Google DNS at 8.8.8.8 answers but the traffic I receive has a source address of 7.7.7.7. This way, the outside world never sees the NATted address.
This way, you could even reach out to external servers using private (destination) addresses, like 192.168.1.8.
Regarding your questions about IP pool and VIP: IP pools substitute the source address, VIP substitute the destination address. A VIP doesn't care for source addresses and vice versa.
The only thing to remember with substituted (NATted) addresses is that in FortiOS NAT happens first, and policying second. You can test that easily.
Hi Ede,
I received a specific question from our customer: Is it possible to set the VIP to change the destination IP address and port?
In this case it is a redirection of requests to address 137.116.197.29 (which is a Samsung time server) to another time server. The network topology is different than in the post by Moa Shee. Our customer has built 13 IPsec tunnels from HQ, and they are terminated in the zone. How to set up a VIP in this case? What type of interface to choose? (There is no 'Zone' there).
Thank you, Jirka.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.