For NAT to work, you must specify a standard access list to identify the traffic that should be NATted. You reference the access list (source list 1) correctly, but you have not created the access list.
Correct NAT config would be:
ip nat inside source list 1 interface GigabitEthernet0/0 overload
access-list 1 permit 192.168.1.0 0.255.255.255
Your extended ...
If you simply have one inside and one outside interface using inside-source NAT, then you may be correct. The problem is that you could have multiple outside and inside interfaces. The interface where the translation happens does not need to be either the outside or inside interface.
For example, you could have two routers, and routers cannot share a NAT ...
"The nat translation works fine, i can ping from the pc on the blue square to the primary router of the yellow square, and vice versa but i cannot ping beetween pcs."
That would be correct because you are using NAPT. If you originate traffic from inside, say from a host in the blue box, the blue router through which the traffic passes will create a NAT ...
There are 2 ways to do this:
1- create 2 policies, one where the destination is the exclusion range, and one following it with the whole destination range. Enable SNAT just in the second policy. Note that policies are matched top-down so no traffic destined for the excluded range should ever hit the second policy.
2- create one policy with the exclusion ...
“ip nat inside” and “ip nat outside” on the interface is what triggers NAT processing.
Once NAT processing is triggered you look for your “IP nat inside source list LAN_ACL...” command to identify the access list to test to see if a NAT translation should occur.
The ACL may or may not match the packet. The source address on the ACL has nothing to do with ...
NAT can't work in that case as Ron has pointed out.
In order to provide end-to-end connectivity for IPv4, a tunnel is required. The tunnel allows you to pass privately addressed packets over the Internet (encapsulated by publicly addressed packets) unchanged. An IPsec tunnel should be preferred as it also encrypts the tunneled traffic.
Apparently, your border router (BR) doesn't know 192.168.x. network. It only knows 172.16.1.0 network and how to route it.
Also, Palo Alto has demarked 192.168.x space as private (secured) so it doesn't want to see that traffic sourced in from untrusted interface.
Hope this helps.
Routers route between different IP subnets, even if those exist within the very same L2 segment (router-on-a-stick). There's no need for translation, just forwarding in between is sufficient.
If you did translate without router that would require splitting the L2 segment in order to force all traffic through the (bridging) translator. NAT without routing ...
You should not use interface address for NAT, use some virutal address
outside static NAT should be configured differently
I repeated your ip address configuration and topology, but my NAT rules are:
ip nat inside source static 10.1.1.2 126.96.36.199
ip nat outside source static 188.8.131.52 184.108.40.206
then when we ping 220.127.116.11 from 10.1.1.2 we have on the ...
With Fortigates, Virtual IP is used for destination NAT. NAT is used for source NATing which you probably don't want as well.
Basically, don't activate NAT in the policy and use the VIP (or VIP group) as destination.
If that doesn't work we'd need the (sanitized) config or GUI screenshots of the VIP and policy settings.
Whenever NAT is used, the source and destination addresses must match the destination's expectations.
With a private IP client sending out a request, the NAT router (or load balancer) translates the private source IP address to one of its own public addresses, forwards the request, and on return from the server it substitutes the destination address with ...
What you are planning to do is called "Destination NAT", and in FortiOS this is done with 'Virtual IPs' (VIPs).
1- create a VIP like this
external interface: LAN2
external IP: 192.168.21.10 (for example)
mapped IP: 192.168.250.23 (for ex.)
port forwarding: not enabled
2- create a policy with
source interface: LAN2
As I understand a packet will be traversing the FORWARD chain only if it is not intended for the local host.
The clarification I have is how will the matching condition of -o $EXTIF be satisfied for any packets. I understand that -i $INTIF will be satisfied as it is the entry interface for the packet.
By the time the packet hits the "forward" ...
As far as I can tell on Linux both approaches are possible. As long as the responses get back to the box doing the NAT it really doesn't matter whether it's through explicit routes or through allocating multiple IPs to the internet-facing interface. The NAT engine is hit before any routing decisions (including the decision on whether to accept the packet ...
I expect you need to use the redirect target in ebtables to pull the packets out of the bridge and into IP routing so that the NAT machinary can see them.
But I haven't actually tried it so I don't know if it will work or what if any gotchas there are.
Under your Policy Rule to allow access from 192.168.60.15 to 10.48.1.4.
Simply select NAT then create a Pool and put IP range of 10.189.1.8-10.189.1.15.
Key thing for this to work is you have route on your fortigate pointing 10.48.1.4 to 10.189.254.17 and finally 10.189.254.17 knows 10.189.1.8-10.189.1.15 lives back via 10.189.254.18.
Thats a pretty ...