What we are missing in our Firewall + NAT configuration?

dadox · Wed Apr 27, 2016 5:17 pm

Hello everyone,

we recently bought CCR1016-12G for our office and now we need to find a way to configure it. Unfortunately, we do not have any experience with MikroTik. But we do understand network fundamentals. Currently, we mainly have Cisco / HP equipment that we are currently looking to replace with MikroTik (for obvious reasons). The configuration logic is quite similar (of course), but not quite the same (again: of course)... And this is what we really need help with.

Let me explain our network setup quickly. We have LAN, DMZ and WAN segments. This particular MikroTik router will stand between WAN and DMZ. We have couple of servers (living inside LAN and DMZ) that we want to publish to WAN. By publish I mean: specific ports / protocols from WAN. And traffic initiated from those servers needs to go to WAN regardless of protocol used. We also want to enable Internet surfing for employees in the office. They will go to the Internet using RRAS server (that stands between LAN and DMZ; it's basically yet another NAT) and that server will forward everything to MikroTik and finally on the WAN. ISP gave us couple of fixed IP addresses we want to use when publishing our LAN / DMZ servers on the Internet. Since ISP router is configured to route all data over just 1 port, all those public IPs will have to be on single MikroTik port as well. If I understand correctly, that definitely should not be a problem. I think that's it. Let me know if you need any additional info regarding setup.

To sum it up: what we have is some quite basic firewall + NAT configuration (static routes, fixed public IPs, fixed LAN / DMZ IPs). Pretty straightforward, right?

OK, so this is the basic configuration we though would work...

# apr/27/2016 15:10:53 by RouterOS 6.30.4
#
/interface ethernet
set [ find default-name=ether1 ] comment=WAN name="ether1 (ISP1)"
set [ find default-name=ether2 ] name="ether2 (NA)"
set [ find default-name=ether3 ] name="ether3 (SERVER1)"
set [ find default-name=ether4 ] name="ether4 (SERVER2)"
set [ find default-name=ether5 ] name="ether5 (RRAS)"
set [ find default-name=ether10 ] name="ether10 (SERVER4)"
set [ find default-name=ether12 ] name="ether12 (CONFIG)"
/ip firewall connection tracking
set enabled=yes
/ip address
add address=A.B.C.30/29 comment=WAN_Default interface="ether1 (ISP1)" network=A.B.C.28
add address=A.B.C.31/29 comment=WAN_SERVER4 interface="ether1 (ISP1)" network=A.B.C.28
add address=A.B.C.32/29 comment=WAN_SERVER1 interface="ether1 (ISP1)" network=A.B.C.28
add address=A.B.C.33/29 comment=WAN_RRAS interface="ether1 (ISP1)" network=A.B.C.28
add address=A.B.C.34/29 comment=WAN_SERVER2 interface="ether1 (ISP1)" network=A.B.C.28
add address=X.Y.3.1/24 comment=DMZ_SERVER2 interface="ether4 (SERVER2)" network=X.Y.3.0
add address=X.Y.1.9/24 comment=DMZ_SERVER1 interface="ether3 (SERVER1)" network=X.Y.1.0
add address=X.Y.0.9/24 comment=DMZ_SERVER4 interface="ether10 (SERVER4)" network=X.Y.0.0
add address=X.Y.0.144/24 comment=DMZ_Config interface="ether12 (CONFIG)" network=X.Y.0.0
add address=X.Y.1.1/24 comment=DMZ_RRAS interface="ether5 (RRAS)" network=X.Y.1.0
add address=X.Y.0.44/24 comment=DMZ_NA disabled=yes interface="ether2 (NA)" network=X.Y.0.0
/ip dns
set servers=8.8.8.8,8.8.4.4
/ip firewall filter
add chain=input comment=SERVER1 dst-address=A.B.C.32 dst-port=20 in-interface="ether1 (ISP1)" protocol=tcp
add chain=input dst-address=A.B.C.32 dst-port=21 in-interface="ether1 (ISP1)" protocol=tcp
add chain=input dst-address=A.B.C.32 dst-port=22 in-interface="ether1 (ISP1)" protocol=tcp
add chain=input dst-address=A.B.C.32 dst-port=25 in-interface="ether1 (ISP1)" protocol=tcp
add chain=input dst-address=A.B.C.32 dst-port=80 in-interface="ether1 (ISP1)" protocol=tcp
add action=drop chain=input dst-address=A.B.C.32 in-interface="ether1 (ISP1)"
add chain=input comment=SERVER4 dst-address=A.B.C.31 dst-port=1234 in-interface="ether1 (ISP1)" protocol=udp src-address=M.N.O.P
add chain=input dst-address=A.B.C.31 dst-port=5678 in-interface="ether1 (ISP1)" protocol=udp src-address=R.S.T.U
add action=drop chain=input dst-address=A.B.C.31 in-interface="ether1 (ISP1)"
add chain=input comment=SERVER2 dst-address=A.B.C.34 dst-port=25 in-interface="ether1 (ISP1)" protocol=tcp
add chain=input dst-address=A.B.C.34 dst-port=25 in-interface="ether1 (ISP1)" protocol=udp
add chain=input dst-address=A.B.C.34 dst-port=80 in-interface="ether1 (ISP1)" protocol=tcp
add action=drop chain=input dst-address=A.B.C.34 in-interface="ether1 (ISP1)"
add chain=forward comment="LAST RULES" in-interface="!ether1 (ISP1)"
add chain=input comment="Allow Established Connections" connection-state=established
add chain=input comment="Allow Related Connections" connection-state=related
add chain=icmp comment="Allow ICMP" icmp-options=0:0 in-interface="!ether1 (ISP1)" protocol=icmp
add chain=icmp icmp-options=8:0 in-interface="!ether1 (ISP1)" protocol=icmp
add chain=forward in-interface="!ether1 (ISP1)" protocol=icmp
add chain=input in-interface="!ether1 (ISP1)" protocol=icmp
add chain=input comment="LAST RULE - ACCEPT ALL FROM DMZ" in-interface="!ether1 (ISP1)"
add chain=output out-interface="!ether1 (ISP1)"
add action=drop chain=input comment="LAST RULE - DROP EVERYTHING"
/ip firewall nat
add action=src-nat chain=srcnat comment=SERVER1 dst-address=0.0.0.0/0 out-interface="ether1 (ISP1)" src-address=X.Y.1.2 to-addresses=A.B.C.32
add action=dst-nat chain=dstnat dst-address=A.B.C.32 in-interface="ether1 (ISP1)" to-addresses=X.Y.1.2
add action=src-nat chain=srcnat comment=SERVER2 dst-address=0.0.0.0/0 out-interface="ether1 (ISP1)" src-address=X.Y.3.2 to-addresses=A.B.C.34
add action=dst-nat chain=dstnat dst-address=A.B.C.34 in-interface="ether1 (ISP1)" to-addresses=X.Y.3.2
add action=src-nat chain=srcnat comment=RRAS dst-address=0.0.0.0/0 out-interface="ether1 (ISP1)" src-address=X.Y.1.3 to-addresses=A.B.C.33
add action=dst-nat chain=dstnat dst-address=A.B.C.33 in-interface="ether1 (ISP1)" to-addresses=X.Y.1.3
add action=src-nat chain=srcnat comment=SERVER4 dst-address=0.0.0.0/0 out-interface="ether1 (ISP1)" src-address=X.Y.0.11 to-addresses=A.B.C.31
add action=dst-nat chain=dstnat dst-address=A.B.C.31 in-interface="ether1 (ISP1)" to-addresses=X.Y.0.11
/ip route
add distance=1 gateway=A.B.C.29

...but it seems we got it wrong.

We cannot get traffic from LAN / DMZ servers to WAN / nor vice versa. Packets / Bytes counters just stand still. And regarding employees surfing over RRAS and MikroTik - do we need some different setup for that?

Bottom line: we are obviously missing some crucial MikroTik-logic-step here. Any ideas where to look? What to check? (P.S. We also have no idea how to efficiently debug MikroTik to check where exactly do packets sink into the void. Any side-help on that topic would be nice.)

Thank you in advance.

blajah · Wed Apr 27, 2016 10:20 pm

Tool torch is what you are looking for. I will check up your config later and try to help a bit.

edit:
From the first quick look, you need to:
1.Mark traffic per public ip and route it back in same manner ( modifying current config)
or
2. Assign public addresses to different interfaces and set up masquerades if servers are NATed or make 1to1 NAT for each server with ACL's
Its just quick look on topology, excuse me if i have misunderstood your goals.

dadox · Thu Apr 28, 2016 10:19 am

or
2. Assign public addresses to different interfaces and set up masquerades if servers are NATed or make 1to1 NAT for each server with ACL's
Its just quick look on topology, excuse me if i have misunderstood your goals.

I will answer #2 part first. We cannot use different interfaces for different public IPs. The ISP router is routing all static IPs over only 1 interface. It is what it is.

Tool torch is what you are looking for. I will check up your config later and try to help a bit.

edit:
From the first quick look, you need to:
1.Mark traffic per public ip and route it back in same manner ( modifying current config)

So I guess this would be a right way to do it then? Could you please share some more info? We thought this would work similar to any other network equipment out there: you setup multiple IPs on the single interface - and that's it (regarding that level of setup at least). If I got you right, you are saying you need to explicitly "explain" to MikroTik there's multiple IPs used (on single inteface) & how to route them?

pe1chl · Thu Apr 28, 2016 11:06 am

You have set many addresses but it is not completely clear to me what you want to accomplish there.
Do you want a separate subnet and connector for each of the servers in the DMZ?
Remember that the addresses you are setting here are addresses of the MikroTik, not of the server.
Usually you want to create a bridge or switch for the DMZ and give the MikroTik a single address in
that, and the servers another address in that same subnet. Of course in some cases it could be desirable
to have the servers isolated from eachother, and then having several subnets is a possibility, but they
would usually be smaller (/30 or maybe /29).

dadox · Thu Apr 28, 2016 11:46 am

You have set many addresses but it is not completely clear to me what you want to accomplish there.
Do you want a separate subnet and connector for each of the servers in the DMZ?
Remember that the addresses you are setting here are addresses of the MikroTik, not of the server.
Usually you want to create a bridge or switch for the DMZ and give the MikroTik a single address in
that, and the servers another address in that same subnet. Of course in some cases it could be desirable
to have the servers isolated from eachother, and then having several subnets is a possibility, but they
would usually be smaller (/30 or maybe /29).

Maybe my explanation wasn't clear enough. Let me try again:

1. We have set of public IP addresses (that correspond to the their public DNS entries).

2. All those IP addresses are on the same subnet (given by our ISP).

3. ISP's router is routing all those IP addresses traffic trough single interface (and thus single UTP cable) towards WAN-entrance point of our DMZ.

4. That WAN-entrance point is MikroTik. So single UTP cable going from ISP's router is plugged into single MikroTik's interface.

5. On the other hand, each server that needs to be NATed is plugged into its own, dedicated MikroTik's interface. Just to clarify: servers do not have public IPs - they have their own DMZ subnets' IP sets. Public IPs are defined only on MikroTik.

6. With that kind of setup, MikroTik shoud be able to perform bidirectional NATing (translating those public IPs to local IPs of actual servers in DMZ; and vice versa) and firewall roles (basically filtering incoming traffic from WAN by defined ports).

7. NATing should be done in a manner 1 public IP = 1 local IP (please see NAT configuration in the original post for more details).

TL;DN
Public IPs (same subnet) are "connected" to single "incoming" interface on MikroTik. DMZ servers are connected to their own, dedicated interfaces. We need to setup NAT and firewall roles between those public IPs and the local ones.

Now, from the previous posts I got the impression the problematic part is that we have all public IPs on the same subnet located on the single interface. Is that correct?

pe1chl · Thu Apr 28, 2016 2:32 pm

Ok, now it is clear!
What you want to do is easy, but you have to know that besides the NAT rules you also need rules in the forward
table that allow this traffic.
Also, it helps for clarity when you keep your rules sorted by chain name...

You can add a single forward allow rule for "Connection NAT state" dstnat.

Remember (or note): "input" rules are for input towards the router itself, "forward" rules are for traffic
forwarded through the router (also for NAT). This may be new when you are used to Cisco style filters.

dadox · Thu Apr 28, 2016 3:03 pm

Remember (or note): "input" rules are for input towards the router itself, "forward" rules are for traffic
forwarded through the router (also for NAT). This may be new when you are used to Cisco style filters.

OK, this is very valuable info. Thank you! Yes, one could easily assume that internal-NAT would work on its own out-of-box. But it seems that's not the case. I can see logic behind it now - it does make sense if you want more granulated and / or complicated setup. Well, every day you learn something new.

Just to sum it up - what you are suggesting is that we put rule like this one...

chain=forward action=accept connection-nat-state=dstnat

...on top of the list, right? And that should do it?

pe1chl · Thu Apr 28, 2016 3:41 pm

Yes, one could easily assume that internal-NAT would work on its own out-of-box. But it seems that's not the case.

Well it does, because that rule is in the default ruleset. At least it is for the most recent RouterOS.
When you have initialized the device with an older RouterOS it is not there and you need to put it in manually.

Just to sum it up - what you are suggesting is that we put rule like this one...
Code: Select all
chain=forward action=accept connection-nat-state=dstnat
...on top of the list, right? And that should do it?

Well, the customary sequence of forward rules is:

1. a rule that sets "fasttrack connection" for packets with connection state Established or Related
2. a rule that allows all packets with connection state Established or Related
3. the above rule that allows dstnat'ted connections
4. a rule that allows all ICMP (although it can be debated if that should not be limited)
5. a rule that blocks all packets with connection state Invalid
6. any further rules for "new" traffic that you want to allow (e.g. directly routed traffic)
7. a drop rule for all the rest

This makes the match hit as early as possible, cutting CPU usage (when the rule 3 has matched one time
on a new connection, the remaining traffic is matched as Established).

dadox · Thu Apr 28, 2016 6:09 pm

I added the rules you suggested, in order you suggested.

But something is still not quite right.

Bytes / Packet counter in NAT tab are standing still (0) for test-server's dstnat route. Only srcnat is showing some kind of activity (when trying to ping http://www.google.com or open it trough the browser). Also if I check Interface list, the test-server's Tx is stranding still (0) and only Rx is showing some activity.

Strangely, ISP interface in the interface list is showing both Tx / Rx.

It seems like dstnat is not working (I might be wrong).

This is what I added on top of the list:

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
established,related
add chain=forward connection-state=established,related
add chain=forward connection-nat-state=dstnat
add action=drop chain=forward connection-state=invalid

P.S.
How to add "4. a rule that allows all ICMP (although it can be debated if that should not be limited)"? What's the best approach?

Thu Apr 28, 2016 6:21 pm

I added the rules you suggested, in order you suggested.

But something is still not quite right.

Bytes / Packet counter in NAT tab are standing still (0) for test-server's dstnat route. Only srcnat is showing some kind of activity (when trying to ping http://www.google.com or open it trough the browser). Also if I check Interface list, the test-server's Tx is stranding still (0) and only Rx is showing some activity.

The nat table rules only get checked once whenever a new connection is established. After that, the NAT table already has the mapping so the kernel just performs the translations as the connections table specifies and doesn't check the nat table chains anymore. Therefore, you're only going to get 1 packet for each new connection to the service.

NETMAP is an exception to this, because netmap is stateless - it doesn't create entries in the connections table, so every packet is individually translated without regard for the past or the future packets in the connection.

pe1chl · Thu Apr 28, 2016 6:37 pm

It seems like dstnat is not working (I might be wrong).

Did you test to connect to the server from an outside address?

This is what I added on top of the list:
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
established,related
add chain=forward connection-state=established,related
add chain=forward connection-nat-state=dstnat
add action=drop chain=forward connection-state=invalid
P.S.
How to add "4. a rule that allows all ICMP (although it can be debated if that should not be limited)"? What's the best approach?

These rules look ok, that is what is present in the (current) default config of RouterOS.
I re-checked the default config and it only allows all ICMP for input, there is no specific ICMP forward rule.
I.e. it will still allowed ICMP related to established connections, due to the first and second rule.
When your dstnat rules specify only addresses and no protocol/port of course they will allow ICMP, so you
can ping the system. When you dstnat only some specific portocol/port and you want to be pingable, you
need a dstnat rule for protocol icmp and icmp type ping request.

dadox · Thu Apr 28, 2016 6:42 pm

The nat table rules only get checked once whenever a new connection is established. After that, the NAT table already has the mapping so the kernel just performs the translations as the connections table specifies and doesn't check the nat table chains anymore. Therefore, you're only going to get 1 packet for each new connection to the service.

Let me get this straight. What you are saying is that NAT table Bytes / Packets columns cannot be used as valid (meaning: real-time & exact) indicator of NAT data flow? And Packets number is just... A number of matched routes? Wouldn't be better if some other column names are used for that? It looks to me as this logic does not follow the rest of MikroTik tables / configuration panels. / But yeah, it's good to know that.

Regardless: if dstnat rule is staning still (0) that means MikroTik didn't find route-match, right? My question is: why? How can I find the exact step when MikroTik decided to drop (or do something else with) those packets? Instead of delivering them by following the rule specified in NAT. It looks like "some rule somewhere" has a greater priority than NAT table. And it's eating packets before they can be NAT-route-matched.

It seems like dstnat is not working (I might be wrong).
Did you test to connect to the server from an outside address?

Yes. Nothing. Any other ideas?

At this point, I am even prepared to test everything with different cables (who knows, right?)... But I want to be sure SW configuration is also OK. It's hard to be 100% sure when you're new at something. So you guys are really helping here. Thumbs up!

Thu Apr 28, 2016 7:13 pm

Let me get this straight. What you are saying is that NAT table Bytes / Packets columns cannot be used as valid (meaning: real-time & exact) indicator of NAT data flow? And Packets number is just... A number of matched routes? Wouldn't be better if some other column names are used for that? It looks to me as this logic does not follow the rest of MikroTik tables / configuration panels. / But yeah, it's good to know that.

First of all - these aren't routes - they're rules. (routes mean something else, and could confuse people)

But yes, this is correct. And it's not wrong in the UI to say packets/bytes matched - it means exactly what it says: how many packets matched this rule, and how many bytes did those packets total. It may not imply what you want due to the behavior of iptables (the technology used by Mikrotik to implement the firewall) but it's correct. It is good to understand the behavior so that your interpretation of what you see is correct. In general, the ip firewall filters rules are going to match all packets - but interpreting THOSE counters is also not quite as straightforward as you might think....

Regardless: if dstnat rule is staning still (0) that means MikroTik didn't find route-match, right? My question is: why? How can I find the exact step when MikroTik decided to drop (or do something else with) those packets? Instead of delivering them by following the rule specified in NAT. It looks like "some rule somewhere" has a greater priority than NAT table. And it's eating packets before they can be NAT-route-matched.

You may want to examine the packet flow diagram.
This shows exactly how packets go through the various chains in the firewall and other configurations of a Mikrotik router.

To answer your specific question about "greater priority than NAT table" - focus on the expanded diagram for routing, and in particular, a packet entering at point I. The first block of items is the [|prerouting|] block, which contains the steps:
Hotspot IN -> connection tracking -> mangle prerouting -> dstnat

If you're not using hotspot, then that step doesn't matter.
Connection tracking is where my previous reply comes into the mix - if a packet has already been mapped with NAT, then this step will match a packet.
Then the mangle prerouting chain does its work, and then we come to dstnat -

dstnat will do nothing if there is an existing connection (from connection tracking) so none of the rules will be checked. This is for efficiency - if the router had to re-process the chain again on every packet, you would lose lots of speed because the CPU would get bogged down much more quickly and not be able to process as much traffic.

Note that the filter table hasn't been used yet.

Therefore, if you're seeing zero hits on a rule, a few things could be the cause:
1) your rule is improperly constructed, and no packet actually matches the conditions you specified.
-- e.g. in-interface=ether1 but you're using pppoe... in-interface should be pppoe1-out and not ether1-gateway
-- e.g. you specify a dst-address, but the router's wan IP is dynamic, and not the same as your rule's dst-address anymore.
-- e.g. typos in the dst-address / dst-port match criteria.
-- e.g. you specified an address-list but the packet doesn't match anything in the list....

2) your WAN interface could be a bridge interface, and some bridging filter rule is blocking the packets before they can reach the IP interface of the router itself... This isn't likely your problem because you would remember setting up filter rules in the bridge menu.

3) some rule earlier in the dstnat chain is matching the packet before it can reach the desired pinhole rule

4) the packets are never even reaching the router in the first place (filtered/misdirected by some device upstream from your router)

4a) This could also happen if your WAN has multiple IP addresses on it, and you're attempting to map one of the other available addresses, different from the WAN IP of the router itself. You need to add the extra IP address to the WAN interface so the router knows to pick them up as well.

My money's on the first two examples of possibility 1.

blajah · Thu Apr 28, 2016 10:21 pm

Hi again,
Can you try to access internet from server with masquerade setup instead of src-nat?
Can you try to remove 0.0.0.0/0 in dst-add for src-nat rules?

Also, when you trace one of your servers public IP's whats your last hop responding to trace? Is it ISP CE routers inside interface(A.B.C.29)? Can you ping it from internet?

Can you trace any internet address from router using source address A.B.C.30 or 31,or 32?
Is your default gateway reachable in route table?

dadox · Mon May 02, 2016 10:31 am

OK, it seems we need to debug low level problems first. When tried to ping 8.8.8.8 using ping tool on the router itself, it seems that router can "go out" to the Internet uses only first A.B.C.30/29 IP address defined on the WAN interface.

If I try to manually setup any other address (A.B.C.31/29 - A.B.C.34/29) in ping tool, it will timeout.

Does that mean the IP set for that interface is not properly defined?

I must admit - I am quite confused right now.

Tue May 03, 2016 5:07 pm

OK, it seems we need to debug low level problems first. When tried to ping 8.8.8.8 using ping tool on the router itself, it seems that router can "go out" to the Internet uses only first A.B.C.30/29 IP address defined on the WAN interface.

If I try to manually setup any other address (A.B.C.31/29 - A.B.C.34/29) in ping tool, it will timeout.

Does that mean the IP set for that interface is not properly defined?

I must admit - I am quite confused right now.

Well, 31-34 is very much an invalid range of addresses for a /29. You have to have a block at least as large as a /26 (1/4 of a class-C) in order for 31 and 34 to be in the same range with each other. Perhaps you just made a mistake in obfuscating your real public IPs...

Assuming that the numbers you're tring to use are really valid for the range from your ISP, you probably just need to add the extra IP addresses to your WAN interface.

Remember, that if I put an IP address of 192.0.2.34/29 on an interface, the interface is only going to listen for exactly that one address,.

dadox · Wed May 04, 2016 2:42 pm

OK, it seems we need to debug low level problems first. When tried to ping 8.8.8.8 using ping tool on the router itself, it seems that router can "go out" to the Internet uses only first A.B.C.30/29 IP address defined on the WAN interface.

If I try to manually setup any other address (A.B.C.31/29 - A.B.C.34/29) in ping tool, it will timeout.

Does that mean the IP set for that interface is not properly defined?

I must admit - I am quite confused right now.
Well, 31-34 is very much an invalid range of addresses for a /29. You have to have a block at least as large as a /26 (1/4 of a class-C) in order for 31 and 34 to be in the same range with each other. Perhaps you just made a mistake in obfuscating your real public IPs...

Assuming that the numbers you're tring to use are really valid for the range from your ISP, you probably just need to add the extra IP addresses to your WAN interface.

Remember, that if I put an IP address of 192.0.2.34/29 on an interface, the interface is only going to listen for exactly that one address,.

No, those are not our real IP addresses (obviously) nor did I pay any attention to put hem in the proper range while posting them. I didn't think it would matter for general NAT troubleshooting. Now it seems we have some low level problems we must solve first.

The story goes:

We have 5 × IP addresses defined on the WAN interface, all from the same IP range. But it seems like only the first one is working while using ping / traceroute tool to test them.

And now comes the interesting part. If i disable first IP address in the list, suddenly I can use the second one just fine with ping / traceroute. If I disable second one, I can use tird just fine. Etc.

Why is this happening?

Wed May 04, 2016 4:44 pm

Nothing special .. you need to specify src-address

/ping 8.8.8.8 src-address=a.b.c.d

dgnevans · Wed May 04, 2016 4:49 pm

When setting up a new config like this as someone new to mikrotik I would suggest start with your initial interface IP's, default routes. Make sure you can ping from the router to internet out etc then move onto the nat statements make sure they working then add the firewall.
the first nat statement I would put in is so my internal devices and machines can get out through the initial setup.

add chain=srcnat action=masquerade src-address=lan.lan.lan.lan/24 dst-address=0.0.0.0/0 out-interface=ether1

once tested lan computers can get out as they should then move onto make each of the servers accessible

set the ip address on the interface ether1, then add nat statement

add chain=dstnat action=dst-nat to-addresses="serverip" dst-address="external ip ISP1"

as you want that server to appear to outside world as that external ip you need to add a src nat statement

add action=src-nat chain=srcnat src-address="serverip" to-addresses="external ip ISP1"

Instead of deleting firewall rules for now disable them and run your tests.

What we are missing in our Firewall + NAT configuration?

What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Re: What we are missing in our Firewall + NAT configuration?

Who is online