6. Static NAT with Port Translation Use Case and scenario example
In this lecture, we’ll talk about static networks with port translation. So there are certain situations where you want to use the same public IP address for different purposes. And this happens in a situation where you’re running out of IP addresses. So let’s say you have a firewall with the DMZ offering public services, and the service provider only gives you one IP, the IP address of the interface, and nothing else. They give you a slash of 30, or they give you five IPS, and you’re trying to make ends meet and figure out how you can have these five IPS or one IP. Use port 84: 43 to host your web server. Use port 25 to host your email server. host your custom UDP server receiver, for example, on UDP port 1000. So you have those three different private IP addresses. Each has a different port, and those ports need to map to the same IP address. That’s what a static network with port translation allows you to do. So you can say that when I have this IP address 150 and am trying to use services that have as their destination port 80 or 43, I will use this IP address 150. When I have a destination port of 25, I’m going to use 151. When I have this UDP application destination port 1000, I’m going to use 152. So each one has its own IP address. So let’s see how the flow works. So traffic goes out, and the traffic goes out to the Internet, and the traffic has a source port, the high port. Assume the web server wishes to communicate outbound on port 84 for three minutes.
Then the static network would match based on source zone, source IP, destination zone, destination IP, destination interface, interface, and service. So when the source zone is DMZ, the IP is 150, and the distinction zone is any destination interface when the destination IP is any destination IP. If the destination service is on port 80, that’s outbound traffic going outbound. Same with the DMZ server that’s hosting email server 51. That email server is used to send SMTP email, and SMTP email to outside sources would have to go over the wire interface. The destination IP address can be any email server in the world. The interface that’s used for egress to the default route is Ethernet, one, and then destination port 25 or service is decision port 25. The UDP receiver is the same. When one UDP port is 1000, the sender UDP receiver is in Distinction Zone 152. So in this case, you are able to host those three services. And when you specify bidirectional in your net, in your static net, and you specify the service, then traffic coming in from the Internet trying to hit, let’s say, 1150 for all those three applications trying to hit destination port 80 is going to go to the web server with destination port 80 because we’re matching based on the static net specified bidirectional based on decision port 80. If it’s coming in, let’s say an email server is sending emails to your email server. And that email that is hitting 1150 on the decision port 25 is going to send this to your email server if it’s coming in from a UDP sender and the destination port of UDP is port 1000.
It’s going to go to that server. So that you are able to satisfy all three servers, hide them behind the same public IPS. So let’s see how to do this in the lab. We created the static net for 11 and 11 on policies.net. That’s fine because this is not specifying a port. And we can add a static net above this rule for each of the three services we have. And we basically had 150. So let’s make this 1515-115-2153. Okay, so basically anything 151 will come into the first IP address this way. Anything that’s destined for 1154, 84, and 43 is going to come into the web server on 151. If it’s coming into 11:50, port 25 is going to go to 152. If it’s coming in as UDP traffic to port 1000 on 111150, it’s going to go to 53. And then anything else that matches 11:11:50 will go to catch all, which is either one or 50. And this is accomplished by placing rules above. So we can create a static net here: static net 1150, TCP, 84, 43. and then the original packet will be the DMZ. The destination interface will be Ethernet destination interfacewill be ethernet one one.And then the services’ HTTP source address. We’re going to specify 170, 217, 151, and 32. That’s the address of that new server’s static IP. And then we’re going to choose the interface IP address, which is 1111, 1150. And then we’re going to specify bi-directional, so that will take care of this one. And then we’re going to clone him and create a new one. This needs to go above “duplicate the wrong rule” or “delete.” So then, clone. And then we’re going to put this one below this one. And we’re going to change the source IP to 172 17, 152.And then we’re going to specify service. Let’s call this service SMTP.
The destination port is 25, and the translated packet has a static IP address of 11:11:50. That’s good. So you can see service HTTP here. If I want to include Https in the same rule, I can create a service that includes both ports, http and https, and then include 84 43 so specified http https. That means it’s going to take care of both ports. This way, you don’t have to create a new rule. and then 152 will be SMTP. And then we’re going to clone it. And then specify here that this is for UDP1000 and create a new service here, UDP 1000. And then the station board says 1000 and translates a packet. Same thing, same interface. Let me change the rule names. This way, we can pinpoint staticnet eleven and change the address. 7217/153/32 is the answer. And I’m going to refer to this as 152 Service 153, UDP $1,000. Okay, now that this is the case, we need to create a security policy. So, for outbound 51, 84, and 43, I’m going to add them as separate rules. The source zone is the postnet source zone, which doesn’t change. The DMZ destination zone is the PostNet source zone, which doesn’t change because that’s outbound and we’re going to use the Internet source IP. We’re going to specify 1217, 151, 32, and then destination. This is for the outbound, which requires separate rules for outbound.Then, in the service application, we’ll specify the HTTPS service we created in the action allow for that, and then clone it. And here we specify 152 SMTP that’s outbound. And then we’re going to change this to one of 7217, 152, or 32 application services. We’re going to change this to the SMTP service that we created.
And then finally, the last one is for the UDP cloned it.So this is from the DMZ; that’s the outbound direction. So we’d be specific, and this way we could easily identify the rules. Make sure that’s correct. DDB 1000, and then the source is going to be 170, 217, 153, 32, and the destination is any service that is UDP $1,000. Okay, now we need to create the rule for incoming traffic, which will basically be now from when to the DMZ. But there’s a difference between outbound and inbound. The pre-net for the outbound is the private IP. The pre-net for the inbound is the public IP. So let’s see how to create the inbound. We’re going to create a new rule. We’ll call this inbound 151-4844-3, and the source is the Wan; that’s the PostNet source destination sources. Any translated traffic from the PreNet PostNet will now be routed to the DMZ and then to the PostNet PreNet IP. The current public IP address is 1111, 1150. So you see here, even though on the outbound we specified the private IP, on the inbound we specified the public IP, and then we’re going to copy this because this is all going to be the same rule, the same traffic, and the same IP address. So sorry, here I need to specify TCP 84 for three. That is where we have information about the service: 84, 4, 3, http: Then we’ll call this rule from the incoming source and destination zones the Porsche net. And that’s what you have to be careful of. 52, port SMTP. And then the destination is service.
We’re going to choose service as MTP. And then, lastly, we’re going to clone this one and create one that’s for the source. We’ll call this 153, which is the fourth GDP 1000. And then we’ll remove SMTP from the service, followed by four GDP 1000. Click okay. And then I’m going to change the enterzone default here that I had enabled. I’m going to change it to “deny,” and then we’ll block all other traffic. And then we’re going to go ahead and commit. So the first thing we need to test is outbound traffic from the DMZ server to the outside world on port 84 43. So let’s see the rule that I’m matching. We’ll go ahead and go to the Ubuntu server. All right, so now we’re going to go ahead and open up the firewall, and then this way we can see the session. So let’s get started with the www.google.com show session. Oh. I need to change the IP. If config. Oh. Now I cannot ping because I don’t have ping allowed. So I’m going to basically make a rule here to allow pings of any kind. We can allow any source, any destination, and any application thing this way. So I’m going to change the interface. If config. If one, then switch it. dinnerpasti 252-5250 7217 151 If you take this route, add defaultgateway and then www.cnn.com.
Okay, let’s allow ping and DNS because it won’t be able to resolve DNS DNS.Okay, now it’s working. Show session. All. so you can see the show session. ID 164. We can see that it was essentially translated to 1150. Let’s see here. Static net, TCP 84:43 And so, basically, that means it was netting with the correct net. And then this is the outbound net through.So that’s for the outbound traffic. What about the inbound traffic? And then 1150. Then, if we do all show sessions, we see show sessions. ID 167. It’s not resolving for some reason. Static net one, TCP, four, four, three. Then there’s the static net DMZ rule. I see the session, but for some reason it’s getting stuck. As a result, the session. ID 170. It’s active. You see the source port here: “random port,” and the dismissal port is 80. And then it got translated exactly as it is. As a result, I interpret the rule as not matching static DMZ. As a result, static net DMZ was $48. So that’s still a match. This is from the previous lecture, but because the IP address didn’t change, the post-prenet IP address is the same for all those rules. So you can easily combine them into one rule. So this lecture is getting too long. I’m going to troubleshoot those issues, and we’ll continue on to the next lecture.
7. Static NAT with Port Translation Use Case and scenario example – part 2
Okay, so this is a continuation of the previous lecture. I had to change the port to UDP 10,000 and the service port. And in my previous lecture, I had hastily configured for TCP instead of VDP, so I changed that to UDP. So let’s test the outbound traffic from the DMZserver to the Ubuntu machine and from the DMZserver to the Windows test machine. I’m going to create a listening port on port 10,000. So, basically, I’m going to download NetCat for Windows, run NC, and then listen on port 10,000, which is listenu P 10,000. And then on the server, I changed the IP address to 153. And then I’m going to run NetCat to try to get to that server on that port.
So I’m sending some texts. I should see the text coming up here. So basically, that confirms that I can send outbound traffic on port 10,000. If we do show session all session two, one, show sessionid to one, we look at the rules. We can see it coming in from the DMV to the Wan and obtaining the source. This is the source for PreNet. The source force net is shown here. The rule outbound one three to P 10,000 is then matched, followed by static net three to P 10,000. So this is the outbound direction. Let’s look at the inbound direction. We’ll set the netcat to listen; that’s lsu 10,000. And then I’m going to do the opposite. Connect to herenetcat U 1111, 1150, and 10,000 from the outside. I should be able to send stuff. So I got it, and when I look at the session, it shows the session ID. So here I am, coming from the Wan, 200, and 222, destination 1150. That’s PreNet ForceNet, which is the opposite direction. The server drops are 122, 17, 153, 200, and 202. And we can see that it matches both the inbound and outbound rules that we created. So we can also test the other one, which is the SMTP. I’m going to set up Ethernet on 1217. And then I’m going to basically run NetCat Solution 125. And then here from the outside, I’m going to try to connect to 425, 1111, and 1155, and then send stuff. Display the session ID.
We can see the client-server relationship as well as the server-client relationship here. In contrast, static net 125 inbound 125 So destroying everything. Oh, but it’s getting stuck on the app ID. It’s basically denying the app ID for some reason while trying to listen to the app. Oh, oh, I got the opposite side. Oh, it’s working. Okay, so if I do outbound, that’s inbound. So I’m going to listen on port 25 and LP 25 here. And then here on the server, I’m going to netcat to 200, 200, 200, 225, and sendtraffic show session for all sessions with ID 206. And we see client to server and server to client, which is translated to 1111 50. And we can see that it matches both the static network and the outbound 152. It’s getting stuck on the app ID. For some reason, it’s stuck on the app ID. So app ID is blocking it. It’s not letting the traffic go through because I don’t see any traffic on the other side. No, it’s coming through. It’s coming through. So you can see the communication across so you can easily test static.net to ensure your policies are working properly. You want to run netcat to test things out.
8. Destination NAT and Destination NAT with Port Address Translation
In this lecture, we’ll talk about destination networks. In the case of a destination net, you will do the same thing to achieve the same goal that we did when we specified a bidirectional static net. But there is an additional feature that gives you additional functionality. So, in the case of static net, we had a DMZ server 150 and one address that was translated to 1150, and we did static net with bidirectional configuration. That means traffic from the DMZ server to the Internet will be translated to 1150, and traffic from the Internet to the DMZ to the public IP address will be translated to 150. So the static net, when you create the static net, you specify the source zone, destination zone, destination interface, source IP, source port, destination port, and then the static net. So in the case of our example here, source zone is DMZ, destination zone is when destination interface is Ethernet 1, source IP is 150, and I’m abbreviating here. The destination port is 80, and the stack is 1150.
So traffic coming in from the Internet on port 80 at 1150 was translated to 150 and sent out the DMZ interface, and we’re checking bidirectional right and destination that allows you to do the same thing. We specify the source zone in the case of the destination network, and the destination zone is going to be when because traffic is coming in from the destined to the when. There are eleven (11) to fifty (50) destination interfaces available, and the Internet interface can be specified. Any destination port of 80 is an Ethernet source IP. In this case, we’ll specify destination.Net, and you can have destination net IP 150, as well as change the port by doing the port and changing it to 8000. So in the case of doing the snatch, you are not able to change the destination port to a different port. In the case of the source network, you cannot really change the destination port to a different port. If it’s port 80, it’s going to have to be port 80. So that’s basically an advantage of doing destinations, and we’re going to see that when you have multiple ISPs as destinations, that allows you a lot more flexibility to handle traffic coming in from different service providers. So that’s basically the difference in our case. We’re going to create a new net here. We’ll create an ad for 1151 and have it connect to port 80.
We’re going to net it to the DMZ server on port 8000, and I set up my DMZ server to listen on port 8000. So let’s go ahead and create the NAT rule. So, on the Nat rule, we’ll add a policy for the DMZ server with the net for 1111, 1151. When the destination interface is ethernet, the source zone is when the destination port is 80, and the destination IP is 32. It will be translated to “destination,” and then to “port,” as you can see here. That is when you can change the port to $8,000 and then translate the address to one 7217. And then this doesn’t conflict even though it’s at the bottom; it doesn’t conflict through any of those rules because there’s nothing here that matches 1151 from the perspective of the static net. And then there’s nothing from when to when to have it in this order on the security rule; we’re going to create a security rule, and it seems like we did. When you configure security rules, you are essentially configuring PostNet, PostNet, source and destination zones, PreNet IP addresses, and PreNet services. So this is the DMZ server: 1111, 1151. When the source-destination zone PostNet is DMZ, this is the source zone. PreNet destination IP is 1111, 1151, 32service. PreNet is on port 80. It will not put 8000 because it looks at the prenet. And then we are going to allow it, commit that change, and test it from the outside.
So here I have my internet, and I see here I’m getting the IP address, and if I do a show, I’m getting the web server. I’m seeing the web server show sessions. All I see here is the session from 200-102, which is my Windows machine. The value of 11 dot 551 is 1717. One dot 50 equals 8000 So let’s see if it matches any security or network rules. Show session ID: two, two, five The client-to-server load is from public to public, the server-to-client load is from private to public, and then there is a destination. The rule for the security rule is DMZ 11, server 11 11 51. It’s matching the rule that we created, and then the net rule is 1111, 1151. It matches the destination of the rule that we created. So that’s an example of a destination ad. When you do destination at, you can change the port and doport translation.
9. UTurn NAT with port translation
So in this lecture, we’ll talk about destination networks. In the case of destination net, for example, many organisations face the problem of users on the inside accessing resources on the DMZ, or even inside, by using the public address. So in that case, they tried to go to the website, for example, the website of the company www.example.com, and this resolved to the public IP address 555-5552. And when traffic from the inside goes to the outside, you want users to return because 55 will not be under lookout and table will be on the internet. The traffic is going to egress out of the outside interface, or the Wayne interface in our case, and then you want it to come back and get to the DMZ. So let’s say the public server is 150.80. So you accomplish this by using destination net, and in that case, you can specify that the source zone is inside, the destination zone is outside, the destination IP is 5520, the destination port is 80, and then translated destination destination.
I’m going to say it’s 154 8000.So because of this, the traffic will get to the outside internet, and then, since basically 55 55 is pointing to the firewall, it’s going to come back to the firewall, which will then forward it out the DMZ interface. In this case, this is the net policy. The security policy that would need to conform to the rules is the source zone; the destination zone is the post-network, which in this case is going to be inside the DMZ. That is the PostNet source IP; any destination IP is 55; the destination port is the PreNet port, which is 80, and that should match the traffic. So let’s create that in our lab. Let’s go ahead and create an app policy. And, if you look at our net policies, you’ll notice that we have a dynamic network that basically nets everything to the outside, to the outside interfaces. So we want to basically create that rule above the dynamic net, otherwise it’s not going to match. So, if I have users on the inside looking for a DMZ server and those users are trying to get to the part where you can specify any and the reason why I specify any, that rule would say, If I have multiple ISPs,
I want to be able to forward it and take care of the multiple ISPs situation. And then the service is servicehtp, and the finishing address is 556-5203. The finished translation will be 132, 175, and 150 pages long, totaling $8,000 in total. Okay, so I’ll move this above dynamic net and then under security policy, and then I’ll need to create an inbound to the Internet pool; I don’t currently have one, so I’ll need to create one so we can test the match. Specifically match Eternal 555-5552, the source zone will be inside, and the destination zone will be the DMZ. Simply post net and then the prenet IP address 555-5203. The PreNet port is 80, and the appropriate action is “allow.” So we’ll go ahead and specify the eternal net here. And technically, I only have access to the DMZ on the inside. This is the only one. So that should be my match. And I’m going to go ahead and click “commit.” I need to create a general rule for insiders to win. This way, I’ll have insider knowledge to win a general rule for that. I don’t have one right now. So I’m going to go ahead and set it inside to win. And action. Let’s go ahead and test it out.
I have a machine on the inside. This machine is the inside test machine. And we’re going to test accessing 55 to 20 on this inside test machine, and there we have a connection. So let’s check. Look at the firewall show session. All show session ID 309. So if we see here the session ID 309, we have the source IP. The inside IP to the public IP is the client to server. The DMZ IP to the private IP is the server to client. And the destination port has changed from port 80 to port 8000. And then this is matching the eternal for 55, 55, and 55 to 20. And the net rule is reversed for DMZ servers. So this is basically how it is done to allow you to connect to the public IP addresses of public services offered on the Internet.
10. Source and Destination NAT
You can also do a source network and a destination network at the same time. And a scenario for this is a situation like the following: Let’s say you have a server inside, and on the inside you have a web server, and you have a client workstation at even 211, and then that server is basically offered to the public on 55 at 30, for example. And what happens is if the workstation tries to access that public server using the public server, using the public IP address instead of the private IP address, the same thing will happen in Utah Net, and then because it’s Utah Net, it’s going to come back and exit out the inside interface. However, because those two devices are on the same network, they will establish direct connections to each other rather than going through the firewall. So that’s a situation where you would want to use sourcenet. What sourcenet allows you to do is, when this traffic gets translated and you turn back, you want to sourcenet the traffic to an IP address on the inside interface or an IP address that’s specifically set on the firewall at 1216 or 120, for example. And the session that appears on a webserver will be the client session; the client IP address will be translated from 111 to 120.
The source IP destination IP is going to be translated from 55, 30, to 150. And because 120 doesn’t exist on the local network, the connection would be going through the firewall instead of going directly to the client. As a result, the client’s IP address is hidden behind the firewall within the interface. Otherwise, the two will establish a session together, and that connection will be broken from the perspective of the firewall, and it will basically not be completed. So, let’s take a look at this in the lab, in our lab. Here, we’re going to set up the Ubuntu server. So, on the Ubuntu server, I’m going to configure an IP address interface if config is zero if onedown first config is zero once we’ve reached 50 routes at default gateway once we do one, that one. So now, on the power side of the firewall, we want to setup the Ethernet, but we’re going to add to that Ethernet. Another caveat is the source translation. So on the net rule, we’re going to create a new Internet for the inside web server, and the original packet is going to be inside. We’re doing the same as we did last time. If you enable it, the IP address destination ServiceService port 80 destination will be 55, 55, 55, 55, 30, 32, and then translated packet. We’re going to do a destination translation, and that destination translation will be for 170, 217, 16, 150, and $48,000, and we’ll also do a port translation.
As a result, we distinguish between translation port and source translation. The source translation will be a dynamic IP import, and then you can specify the translated address as 170, 216, 120, and 32, okay, so that should take care of that. So, on a security policy, because intrazone is inside, it will be interzone. So it’s going to match the intrazone. So we want to create a specific one. We’ll create a rule for the inside-to-inside turn. So the source will be the PreNet source. The source zone will be located within the post-net zone, and the pre-net IP will be 555-5303. The PreNet service is then serviceHTTP. So this way we match the rule exactly and then click OK, so now it’s ready. I’m going to go ahead and commit, so as soon as it finishes 555, 55, 30 show session ID 326, I should be matching 172:16 from the inside test machine. So I see the server now. So it’s here: client to server is 172, 16111, and then server to client, you see the destination has changed because 111 was hidden behind the source network of 3216, 120, and then 55, 30 was changed from the station reverse floor to the server, which is 50. The port was changed from 80 to 8000, and then the rules matched the inside to inside UTR that we created. Then you look for what’s inside. So that shows you an example of doing source-and-destination networking to avoid a situation where the firewall does not see the entire session. So if you remove the source network, you’re going to have an issue because of the firewall, and the client will connect directly. So let’s remove the source net from this rule that we created to show you the issue that I was talking about. I’m going to remove the source network, and as soon as I remove the source network, the two devices will not be able to communicate with each other because the problem now is they’re going to bypass the firewall when they talk to each other.
So let’s try it again. It’s waiting because the session hasn’t been fully established yet. It’s going to be stuck in there because the firewall sees only one side of the floor. It saw the sin, but the scene action returned directly to the firewall and didn’t return directly to the machine. So I don’t see the session properly bypassing the firewall on the return because the two established sessions with each other; it appears that I should clear the cache, close the browser, and reopen it. It’s stuck waiting for the session ID; it’s not pulling up, which is the reason why it’s bypassing the firewall, so that’s one of the reasons you would do source translation. There are other scenarios; there are multiple scenarios where source translation comes in handy, and there are a lot of situations where this comes in handy. So that’s an example for you on how to do source and destination translation. And in fact, we do source, destination, and address translations as well, so that kind of catches all those different scenarios.
