I am trying to do natting by creating object with IP address which is in subnet not connected to firewall-1 and natting it to an IP address that is also not connected. In fw monitor it is only showing pre-in. how can I do so?
Thanks in advance.
I am trying to do natting by creating object with IP address which is in subnet not connected to firewall-1 and natting it to an IP address that is also not connected. In fw monitor it is only showing pre-in. how can I do so?
Thanks in advance.
A route elsewhere in the environment to direct the traffic for the source IP is required.
If you're seeing the traffic at all in fw monitor, that most likely means the traffic is being routed to the firewall correctly.
If it's not going past pre-in, that suggests the firewall rulebase is not configured to allow the traffic.
That is also a requirement.
What rule(s) in your rulebase allow traffic to this IP?
Are you configuring the NAT IPs in the object or are you using the NAT rulebase?
What does your logs say when someone tries to connect to the IP address?
Not only is neither subnet attached to the FW-1, they are off the same interface.
It's not impossible.
In fact, more than 15 years ago, I had devised a solution a similar problem.
Before you can even discuss the NAT rules on the firewall, there are several other things you will need to do in the environment to ensure 172.20.20.222 even reaches the firewall.
Specifically:
Once you've done that, there will need to be a firewall rule permitting connections from the relevant hosts to 172.20.20.222.
In order to ensure that the firewall stays between the connection between the two hosts, you will need to create a manual dual NAT rule.
The NAT rule will look at both the source and destination of the packet and translate both the source and the destination of the packet.
Because the rules are processed in order, the dual NAT rule must come before other rules that might relate to the destination IP.
Note that since you did not say what IP your firewall is on the 10.2.0.0/24 network, I am going to assume it's 10.2.0.1 in this example.
You also need to specify what IP addresses the connection will come from, as it cannot come from ANY.
Let's assume it's coming from 10.20.1.0/24.
Source | Destination | Service | Source | Destination | Service |
10.20.1.0/24 | 172.20.20.222 | Any | 10.2.0.1(H) | 192.168.1.222(S) | Orig |
This rule will ensure all traffic coming from 10.20.1.0/24 that is destined for 172.20.20.222 will get hidden behind 10.2.0.1 (the internal IP address of the firewall) and have a destination of 192.168.1.222.
The side effect of this is that for each connection to your "internal" SMTP server using the external IP address, you will see the network connection traverse your internal network twice:
Plus you've created a whole bunch of extra routes in your network that you have to maintain.
Not only is neither subnet attached to the FW-1, they are off the same interface.
It's not impossible.
In fact, more than 15 years ago, I had devised a solution a similar problem.
Before you can even discuss the NAT rules on the firewall, there are several other things you will need to do in the environment to ensure 172.20.20.222 even reaches the firewall.
Specifically:
Once you've done that, there will need to be a firewall rule permitting connections from the relevant hosts to 172.20.20.222.
In order to ensure that the firewall stays between the connection between the two hosts, you will need to create a manual dual NAT rule.
The NAT rule will look at both the source and destination of the packet and translate both the source and the destination of the packet.
Because the rules are processed in order, the dual NAT rule must come before other rules that might relate to the destination IP.
Note that since you did not say what IP your firewall is on the 10.2.0.0/24 network, I am going to assume it's 10.2.0.1 in this example.
You also need to specify what IP addresses the connection will come from, as it cannot come from ANY.
Let's assume it's coming from 10.20.1.0/24.
This rule will ensure all traffic coming from 10.20.1.0/24 that is destined for 172.20.20.222 will get hidden behind 10.2.0.1 (the internal IP address of the firewall) and have a destination of 192.168.1.222.
The side effect of this is that for each connection to your "internal" SMTP server using the external IP address, you will see the network connection traverse your internal network twice:
Plus you've created a whole bunch of extra routes in your network that you have to maintain.