Community discussions

MikroTik App
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Port Forwarding not working

Thu May 03, 2007 6:38 pm

Hello,
I am very new to the OS, but follow instructions well. I followed several samples on the wiki detailing how to forward requests on a certain port, to a specific internal IP. These dstnat rules are not working for me for some reason. Once I have created them, I can see the counters incrementing in winbox for the rule...however I am still unable to connect to the resource. Below is a print paste of the two rules I cant get to work:

chain=dstnat in-interface=public dst-address=(public IP) protocol=tcp
dst-port=22 action=dst-nat to-addresses=192.168.0.100 to-ports=22

chain=dstnat dst-address=(publicIP) protocol=tcp dst-port=3389
src-address-list="" dst-address-list="" action=dst-nat
to-addresses=192.168.0.50 to-ports=3389

*I replaced my public ip of form xxx.xxx.xxx.xxx for privacy's sake.
Any help or reccomendations would be greatly appreciated...I am stumped.
 
User avatar
usrox
just joined
Posts: 23
Joined: Sat Sep 17, 2005 7:59 am

Thu May 03, 2007 9:25 pm

Hi, i have similar config for port redirect to my local server and it works perfectly

chain=dstnat dst-address=[public ip] protocol=tcp dst-port=80
action=dst-nat to-addresses=172.21.2.2 to-ports=80

chain=dstnat dst-address=[public ip] protocol=tcp dst-port=22
action=dst-nat to-addresses=172.21.2.2 to-ports=22
 
User avatar
andrewluck
Forum Veteran
Forum Veteran
Posts: 700
Joined: Fri May 28, 2004 9:05 pm
Location: Norfolk, UK

Thu May 03, 2007 10:23 pm

Do you have any src-nat or masquerade rules for outbound traffic?

Regards

Andrew
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Thu May 03, 2007 11:19 pm

Yes I do. The only other rules I have presently are a port 80 redirect on the internal (private) interface to the web cache. And a masquerade srcnat for NAT.

chain=srcnat out-interface=public action=masquerade

chain=dstnat in-interface=private protocol=tcp dst-port=80 action=redirect
to-ports=8080

Is the masquerade causing a problem (breaking the connection as the host is not receiving info back from the expected IP?) I suppose that would make sense to me logically, but i dont know how to get around it.
Thanks ,
Jeremy
 
User avatar
andrewluck
Forum Veteran
Forum Veteran
Posts: 700
Joined: Fri May 28, 2004 9:05 pm
Location: Norfolk, UK

Fri May 04, 2007 12:25 am

NAT rules look OK. You haven't mentioned firewall rules.

Otherwise, routing tables?

Run ethereal on one of the servers and check that the inbound packet actually arrives.

Regards

Andrew
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Fri May 04, 2007 4:42 am

Hi again,
There are no routing entries outside of default. There are currently only 3 entries in routes, all default. I have not done anything further than run setup, enable dhcp,transparent web proxy, local dns. Another clue, I attempted to redirect a user using a dst nat rule from their source IP, dstnat port 80 to the address of my internal webserver, and that to appeared not to work. Let me know if I could paste anything else that would be helpful. A side note, I really appreciate your being helpful on this issue...user forums and helpful souls such as yourself are ideal.
Jeremy
 
ptsip
newbie
Posts: 43
Joined: Fri Jan 20, 2006 7:17 pm

Fri May 04, 2007 5:08 am

A little mistake you made, pls delete in-interface=public for the following chain:

chain=dstnat in-interface=public dst-address=(public IP) protocol=tcp
dst-port=22 action=dst-nat to-addresses=192.168.0.100 to-ports=22
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Fri May 04, 2007 5:30 am

Thank you for the input psip. I went ahead and made the change to remove in-interface, and still have the same problem. I believe that is something I did going back and forth trying to get this working. Without that parameter specified, both rules for ssh and rdp still fail to work, even though you can see the packet counter for the rule incrementing. On another note, ethereal does see packets arriving when attempting to rdp to the device. It almost seems as though the traffic is only flowing in, and not allowing any return communication? Either way, im stumped.
 
ptsip
newbie
Posts: 43
Joined: Fri Jan 20, 2006 7:17 pm

Fri May 04, 2007 7:42 am

Just to make sure that your internal server for rdp and ssh have the correct gateway to internal ip mikrotik. OK?
 
pjulian
Member Candidate
Member Candidate
Posts: 267
Joined: Mon May 31, 2004 12:16 pm
Location: Sydney, Australia

Fri May 04, 2007 8:37 am

So you can definately connect to these ports OK from inside the network, and you can definately ping your public addresses from outside ?
Maybe temporarily allow port 22 in the input chain and test to make sure you can SSH to the router itself, work through it piece by piece.

You rules look OK to me and should work, even the one with the in-interface should work, but you don't need that set.

Regards
Paul
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Fri May 04, 2007 6:30 pm

Hello Paul,
Yes, I can connect to both with no error from inside the network. I also confirmed that both had the correct subnet and gateway, and could communicate with the MT with no issue. At your recommendation I also created an input chain for port 22, and see the same behavior (connection timed out) when attempting to connect to the external IP. I have pasted all firewall>filter rules below. I really appreciate all of your help, please let me know if I can give you any more information.
Jeremy
[admin@MikroTik] ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward in-interface=public action=jump jump-target=customer

1 ;;; Drop invalid connection packets
chain=customer connection-state=invalid action=drop

2 ;;; Allow established connections
chain=customer connection-state=established action=accept

3 ;;; Allow related connections
chain=customer connection-state=related action=accept

4 ;;; Log dropped connections
chain=customer action=log log-prefix="customer_drop"

5 ;;; Drop and log everything else
chain=customer action=drop

6 chain=input protocol=tcp src-port=22 action=accept



[admin@MikroTik] ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat out-interface=public action=masquerade

1 X chain=dstnat in-interface=private protocol=tcp dst-port=80 action=redirect
to-ports=8080

2 chain=dstnat dst-address=xxx.xxx.xxx.xxx protocol=tcp dst-port=22
action=dst-nat to-addresses=192.168.0.100 to-ports=22

3 chain=dstnat dst-address=xxx.xxx.xxx.xxx protocol=tcp dst-port=3389
src-address-list="" dst-address-list="" action=dst-nat
to-addresses=192.168.0.50 to-ports=3389
 
pjulian
Member Candidate
Member Candidate
Posts: 267
Joined: Mon May 31, 2004 12:16 pm
Location: Sydney, Australia

Sat May 05, 2007 1:51 am

Rule 6, you need to change to dst-port, then try to connect again, making sure of course that you disable the relevant forward rule for port 22.
What I was trying to get you to do is connect to the port 22 (SSH) on the mikrotik itself just to ensure that you can get port 22 into the router. Also, I'm not sure if you have port 22 enabled on the router if it will cause any problems with forwarding it, it shouldn't, but it may pay to disable that service in IP->Services just in case.

Regards
Paul
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Mon May 07, 2007 11:27 pm

Thanks for the input pjulian. I have tried that , and am still at the same point. Any one else?
Jeremy
 
savage
Forum Guru
Forum Guru
Posts: 1265
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Tue May 08, 2007 12:19 pm

The IP Address of the Internal Interface is???

In order to use dst-nat, your dst-nat destination address (to-address=) needs to be on the same IP Network as the Interface where the data leaves.

If you dst-nat to-address=172.21.2.2, then the Internal Interface on the Mikrotik need to be on the same IP Network. It needs the MAC Address in order for dst-nat to function, and if you are dst natting to a routed IP address, the router will not know the MAC address of the destination IP.
 
rburke
just joined
Posts: 3
Joined: Mon Jun 20, 2005 11:12 am
Location: Ireland

Tue May 08, 2007 10:49 pm

Hi Jeremy,
as you declared "rule 6" to allow port 22 in firewall filter for SSH connections - did you aslo define port 3389 there to allow incoming RDP connections :)

Rory
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Fri May 18, 2007 11:38 pm

Thanks for the help savage. The internal IP address of my "private" interface is 192.168.0.2/24. Is this causing a problem?
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Fri May 18, 2007 11:38 pm

Thanks for the help savage. The internal IP address of my "private" interface is 192.168.0.2/24. Is this causing a problem?
 
pinam
Trainer
Trainer
Posts: 16
Joined: Mon May 29, 2006 2:45 pm
Contact:

reorder firewall

Mon May 21, 2007 1:40 pm

I only came across this thread and I found 2 things.

1\ I do not agree that address where the communication is dst-nated has to be from the same subnet as the address of the interface through which it is leaving. However, the dst-address has to exist (naturally) and you have got to have a route to it, if you want it to work.

2\ In my opinion you do not need to allow port 22 as extra action since there is no rule to deny it. Moreover communication to ssh is normally where dst-port is 22, not the source one, source ports are allocated dynamically.

Although I came across it very quickly I have not found why it should not work. Try to use torch/ethereal and other tools to state whether packets are redirected correctly and not processed because of other reasons, for example.
 
wtw
just joined
Posts: 9
Joined: Mon May 08, 2006 3:35 am

Re: Port Forwarding not working

Tue May 29, 2007 5:33 am

I have a similar issue and wanted to know if anyone has a fix or know how to resolve:

Port forwarding works but only if you are on the outside of the private network. For example I can sit outside and get to all my email and webservers no porblem.

Once inside tring to pull up any service pointing to the outside IP it dies at the MT box?

There are no firewall rules except for dst-nat at this time. Curious to know that I can stick a cheap linksys in and everthing works just fine from both sides.

Thank you in advance!
 
galaxynet
Long time Member
Long time Member
Posts: 646
Joined: Fri Dec 17, 2004 2:52 pm
Contact:

Re: Port Forwarding not working

Tue May 29, 2007 3:38 pm

Wtw -
[admin@MikroTik] ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward in-interface=public action=jump jump-target=customer

1 ;;; Drop invalid connection packets
chain=customer connection-state=invalid action=drop

2 ;;; Allow established connections
chain=customer connection-state=established action=accept

3 ;;; Allow related connections
chain=customer connection-state=related action=accept

4 ;;; Log dropped connections
chain=customer action=log log-prefix="customer_drop"

5 ;;; Drop and log everything else
chain=customer action=drop

6 chain=input protocol=tcp src-port=22 action=accept


[admin@MikroTik] ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat out-interface=public action=masquerade

1 X chain=dstnat in-interface=private protocol=tcp dst-port=80 action=redirect
to-ports=8080

2 chain=dstnat dst-address=xxx.xxx.xxx.xxx protocol=tcp dst-port=22
action=dst-nat to-addresses=192.168.0.100 to-ports=22

3 chain=dstnat dst-address=xxx.xxx.xxx.xxx protocol=tcp dst-port=3389
src-address-list="" dst-address-list="" action=dst-nat
to-addresses=192.168.0.50 to-ports=3389

Filter Rule #6 - should be deleted. Besides you have this rule after all of your other rules so it is dropped and logged before it even gets to it...

NAT Rule #3 - "src-address-list="" dst-address-list="" " are you using src and dst addresses here? If not then get rid of these parameters...they'll just cause problems otherwise.

In the above set of rules I do not see an allocation for a 'new' connection. You have related, established, and invalid - where is new?

You are ONLY filtering requests coming from the outside - "in-interface=public", was this your intention?

I also don't know how you 'allow' connections to your servers, one of the security features I use among others is IP addresses...if you use this feature then you will also have to match the masqureaded IP from the MT and add it to your list of 'allowed' IP addresses for your servers...because you have ALL requests for external IP addresses masqueraded "0 chain=srcnat out-interface=public action=masquerade ". When connecting using an inside IP address you'll have to do the same on the server - the MT isn't involved - it's a direct connection from client to server but the IP address of your client will need to be in the 'allow' list on the server....



Thom
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Re: Port Forwarding not working

Sat Jul 14, 2007 12:53 am

I FIGURED IT OUT!!! it was a damn filter rule "Drop and log everything else". I disabled this rule, and everything works...yay! Any problems with leaving this rule disabled, or perhaps editing the filter rules to allow that traffic?
Thanks,
JZ
 
User avatar
skillful
Trainer
Trainer
Posts: 552
Joined: Wed Sep 06, 2006 1:42 pm
Location: Abuja, Nigeria
Contact:

Re: Port Forwarding not working

Sat Jul 14, 2007 12:17 pm

Just make the "Drop and log everything else" rule the last rule in your filter table and it should be okay to enable it.
 
ziggyrocket
just joined
Topic Author
Posts: 10
Joined: Wed Apr 20, 2005 8:53 pm

Re: Port Forwarding not working

Sun Jul 15, 2007 5:35 pm

It is currently the last rule in the sequence and when enabled it is still filtering out that traffic.
-JZ
 
User avatar
skillful
Trainer
Trainer
Posts: 552
Joined: Wed Sep 06, 2006 1:42 pm
Location: Abuja, Nigeria
Contact:

Re: Port Forwarding not working

Sun Jul 15, 2007 9:16 pm

It is currently the last rule in the sequence and when enabled it is still filtering out that traffic.
-JZ
You need to create accept rules for that traffic

Who is online

Users browsing this forum: BartoszP, DoryIII, yawpyng and 21 guests