News: This forum is now permanently frozen.
Pages: [1]
Topic: Port forwarded traffic still dropped  (Read 3159 times)
« on: November 14, 2011, 03:53:24 »
bkendall *
Posts: 5

Hello all,

I'm having trouble with port forwarding - the firewall rule and NAT rule seem to be set up correctly, but the packets are still being dropped according to the logs.

Network topology is really simple; Mono runs on a two-NIC box. I have a computer behind the firewall running an application that listens on TCP 51234.

I have the following rules set up on the firewall:

Firewall: NAT: Inbound
If         Proto     Ext Port Range     NAT IP                   Int Port Range   
WAN    TCP       51234                192.168.200.195     51234

Firewall: Rules: WAN
Proto     Source     Port     Dest                        Port            Action
TCP         *             *         192.168.200.195   51234         Pass


From what I can tell, these rules are set up correctly. The interesting thing is that in the firewall logs, the traffic is still dropped. I have no other rules set up on the box, other than the default that blocks RFC 1918 inbound on the WAN interface.

Any ideas?

Thanks!
« Reply #1 on: November 15, 2011, 03:10:30 »
bkendall *
Posts: 5

Bump
« Reply #2 on: November 15, 2011, 19:18:47 »
iridris ***
Posts: 145

Perhaps try changing the protocol to ANY to see if that changes anything? What application is it?
« Reply #3 on: November 22, 2011, 22:47:13 »
rafaelmagu *
Posts: 5

Hi there,

I'm having the exact same issue. And worst: on two different installs of m0n0wall. I've set up rules to forward port 8080 on the WAN side to an internal host's port 80, but they simply don't work. I don't know what else to try.
« Reply #4 on: November 22, 2011, 23:02:55 »
bkendall *
Posts: 5

Sorry, I've been away.

I've tried changing to ANY with the same results. The application is Maptool (yes, I'm a true geek - http://www.rptools.net/index.php?page=maptool).

I've verified that I'm running the most current version as well - 1.33 for generic PC with keyboard, monitor, and HDD.
« Reply #5 on: November 22, 2011, 23:22:40 »
Manuel Kasper
Administrator
*****
Posts: 364

@bkendall and @rafaelmagu: can you please post (or e-mail to mk@neon1.net if you prefer) the output of <http://m0n0wall/status.php>? That would help in debugging this issue.
« Reply #6 on: November 22, 2011, 23:30:22 »
bkendall *
Posts: 5

Status page emailed.

Thanks!
« Reply #7 on: November 23, 2011, 00:03:38 »
rafaelmagu *
Posts: 5

Sent through to email from both of the installs I have.
« Reply #8 on: November 23, 2011, 03:19:55 »
bkendall *
Posts: 5

Alright, my issue is fixed.

I deleted both the NAT and firewall rules and started over. It helped to check the box on the firewall rule to "log packets handled by this rule", which did show in the firewall logs that the traffic was being allowed. Not sure why it was being denied the first time around, but I'll chalk it up to something that I misconfigured.

Secondly, the native firewall on the server was blocking the connection. It was "supposed" to be disabled, but a network capture indicated the remote computer sent three SYNs, received no reply, and then timed out.

Many thanks to those that tried to help, especially Mr. Kasper.

« Reply #9 on: November 23, 2011, 03:25:35 »
rafaelmagu *
Posts: 5

Good to hear. I kept working a little bit on it but I'm still seeing the same issue.

The second m0n0wall install was done on Monday, so all the rules have been created brand new.

I did, however, setup an IPsec trunk now between the two setups which works, except for the fact that the internal subnets are not visible from either side (subnet A is not visible from behind m0n0wall B and vice-versa). I can, however, open both web interfaces when I connect to one of the m0n0walls using PPTP, which means traffic is going through the link, just not being allowed through m0n0wall.
« Reply #10 on: November 23, 2011, 21:03:48 »
rafaelmagu *
Posts: 5

So the issues have finally been fixed. I was also using Captive Portal on both sides, and CP was blocking traffic on the PPTP interface as well, which was unexpected because PPTP doesn't show up in the drop-down for CP configuration.

I had a rule in CP to allow traffic TO a local IP address (RADIUS server I was trying to reach from outside), but the rule actually needed to be FROM, so traffic could come back to me. It's a bit confusing that they use that naming convention instead of WAN/LAN, but I understand now that FROM is when you want traffic to go to a certain IP on a different interface than your own.

Secondly, the NAT rules are processed BEFORE the firewall rules. I had my thinking the other way round. Once Manuel clarified that for me, I was able to switch the rules around and everything works, including CP.
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines