My LAN has several systems on it. One of the systems, 192.168.10.15, runs an Apache Server that only accepts http traffic. That’s working fine as I have forwarded port 8013 to that system. I have a need to redirect incoming traffic through the HTTPS protocol port 443. My server is already operating internally with both ports, but do I need to know how I can redirect this traffic on this port 443?
I assume that all I need is to set up port forwarding entry to foward all Internet traffic arriving for port 443.
Well that wasn’t all that fancy. All CZFAN did was combine two separate rule into one rule on the DSTNAT side. There was nothing wrong there with the two rules, but one can put more than one port in the port entry slots.
Further, typically a firewall filter rule is NOT required for port forwarding. (Note: Personally I don’t like any port forwarding where I don’t limit the incoming internet IPs to a source address list.)
However, since his clairvoyant “wild assed guess” suggestion seemed to fix things I can only conclude that:
you have a DROP ALL rule at the end of your Filter FORWARD Chain.
I would be curious if his rule could be shortened as I don’t think the endy bits are required.
( no need for connection state established, related etc.)
There should already be a rule for established and related connections as one of your first rules in the Filter FORWARD Chain.
If you try this does it still work?
/ ip firewall filter
add chain=forward action=accept in-interface=wan_interface connection-nat-state=dstnat
I know English is not my first language, but I have reread the OP’s post, and I can’t find anywhere where it was requested for a “fancy” solution, maybe you can elaborate a bit so I can understand where you coming from?
Or do you think I should have suggested additional “bridges” as a “fancy” solution?
Oh you are going hold my bridge obsession over my head for awhile LOL.
Well you will be happy to know that I have concluded one bridge is enough as two bridges breaks HW offloading! When I get to implementing approx 3 vlans I will come back begging for help.
“Fancy” was both a compliment and 'why didnt I think of that jealous moment" wrapped up in one word!
The important piece was how the heck did you know it was allowing dstnat connections in the forward filter rule which was the issue?
Second, I have the same rule now but I dont have the established and related part of the rule. Why did you include it?
(PS. If this silly site had IMs, I could tell you my life story)
CZFAN, no apologies needed or accepted, I found your post to be both amusing and witty and spot on due to containing historical context to my previous crappy posts LOL.
I enjoy our dialogue!! Please do not refrain from being colourful!!
More to the point answer the damned questions Pretty Please (or i could start to make the case of you being Sobs brother due to obtuse answers ).
Q1. The important piece was how the heck did you know it was allowing dstnat connections in the forward filter rule which was the issue?
Q2. Second, I have the same rule now but I dont have the established and related part of the rule. Why did you include it?
Thanks for expanding my vocabulary (I’m non-native speaker, so it’s not hard), but you could choose some nicer words next time.
And without trying to steal the show, this whole thing looks suspicious. If dstnated connections were otherwise blocked, then combination of connection-nat-state=dstnat and connection-state=established,related wouldn’t help much by itself, because initial SYN packet will have connection state “new”. And if that one doesn’t get through, there won’t be any connection. So it would be good to review all rules, to know what exactly happens.
Your are potentially maybe, perhaps achieving an inkling of truth… perhaps I should have used obfuscation in my oratory.
However, I digress! I too seek more clarity on this thread, in regards to what was the key issue preventing OP success and how CZFANs advice was magically correct and how the OP actually used it.
(PS. Your ability to find my Sob references in the most obscure places is rather alarming, I keep looking for a camera behind my desk)
Don’t worry, it’s not you, it’s more the “port forward” in title, it’s one of my trigger words. Plus being here in forum is important and frequent part of my procrastination routine.
Or do worry, because the above is exactly what I’d write if I did have hiddden camera behind your desk.
2 rules could be combined for better efficiency
OP keeps referring to port 8013 in his description of problem, but the rules he showed, the one FW filter rule showed port “80”, and the better way to do this was to use the connection=dstnat way
Hi.
I apologize if my question is not directly related with the topic, but I am interested in this filter rule: /ip firewall filter add chain=forward action=accept in-interface=wan_interface connection-nat-state=dstnat
I understand this rule allow all destination nat defined in nat rules. Is it correct?
If any dstnat rule is applied to connection, info about it sticks with connection and you can match packets belonging to dstnatted connections using connection-nat-state=dstnat. The rule as is should be ok in most cases, and you don’t even need in-interface=wan_interface. Adding any connection-state condition is usually not necessary, because when you dstnat connection, you want all its packets to pass. Plus if you have the usual config, where you deal with established/related/untracked/invalid right at the beginning, then new state is all what’s left for all further rules, so there’s no need to specifically check for it.
I have the rule in place because my last forward rule is DROP ALL. Thus dstnat connections would also get dropped.
I also assume that the more definitions in place for traffic, the harder it is to spoof.
It’s not that categoric. A rule with connection-state=established makes an otherwise same rule with connection-nat-state=dstnat redundant if it precedes it. A connection which is established may or may not be dstnat, but every dstnat connection is either new or established, and you probably have some accept rule for new which accepts the initial packets regardless whether they are dst-nated or not.
Can you provide an example? E.g. a rule with connection-state=established connection-nat-state=dstnat is definitely more restrictive than a rule with just one of these conditions, but I cannot see any additional protection against spoofing.
Did I say that ? action=accept chain=forward connection-state=established,related will work for every packet except the initial one of a connection. It is your choice whether you use connection-nat-state=dstnat as the criteria to accept that initial packet, or whether you use some other ones.
Use of connection-nat-state=dstnat connection-state=new is a good approach if already your dstnat rules are restrictive enough (or you need no restrictions), because in such case, a single filter rule permits establishing of all dstnat connections (and the actual filtering, if needed, must have been done in the dstnat chain already). But it is more usual to let nat do nat and filter do filtering. That’s why I wrote
This statement of yours
made me think that you use connection-nat-state=dstnat to make it harder for an attacker to imitate a packet which would match connection-state=established,related, not to accept new dstnat connections. Or maybe you mean something else by “to spoof”?
Great answers which pick apart my lack of knowledge.
Sadly I have never had a forward chain accept rule for anything NEW?
In fact at this expert link… https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
uou will note that there is no NEW noted anywhere similarly one will not see NEW in a the default setup.
Furthermore another confounding issue is the missing untracked which comes in the default setup BUT NOT in the link above. Drives me crazy
I think it was you or SOB said dont need untracked unless your doing something funky in RAW rules.
Mikrotik make up your mind LOL.
So lets go back to dsntnat type connection.
I have the NAT rules in place for all my incoming unsolicited connections (note all limited to external user WANIP addresses)
Are you saying that my filter Rule should be modified to look like this
/ip firewall filter
add chain=forwarding action=accept connection-state=new connection-nat-state=dstnat
(vice add chain=forwarding action=accept connection-nat-state=dstnat)
As so far as the other issue. Yes, the more items that define a traffic flow or rule should be harder to spoof, dont you agree!!!
Spoof = Hoax or trick (someone), i.o.w. you are tricking the firewall that you are coming from th.is.ip.ad.dress, but not your real address. So even if you make the firewall rules more restrictive, i.e. more parameters such as using an address list, if the baddy is spoofing with one of those addresses in the address list, then no it will not prevent spoofing.
So spoofing is really something else, although related, confusing
Re the “new” state not in default config rules, I have heard from some that it is not necessary, as you have established, related in place or something to that effect, but I never paid attention to it, and I am old school, so I control my traffic with both “new” states and “Est, Rel” states.
My “New” states coming in from wan, goes one path where it checks if I trust this connection, if not, I drop, if yes, I allow and then that connection will follow the faster fasttrack way with establish, related.
Having more or less parameters in FW rules, that is based on scenario, for me, I add parameters so the rule can do what it must and not interfere with other rules, i.e. you can have a FW rule with little parameters, chain=forward protocol=icmp action=drop which is a fairly generic rule. But what happens now is even when I ping google from LAN my packets get dropped. I want to allow ICMP freely inside and from inside my network, so I change the rule to be a bit more restrictive, i.e. ad connection-state=new and in-interface=ether1. No I can use ping freely inside my network, to the outside of my network but coming in from the WAN will be dropped
).
? action=accept chain=forward connection-state=established,related will work for every packet except the initial one of a connection. It is your choice whether you use connection-nat-state=dstnat as the criteria to accept that initial packet, or whether you use some other ones.