Sorry, it was a bad ACL on the other router that was causing the problems. 
Problem has been solved.  Thanks.

I ran across a similar issue today - pfSense 2.0.1.  Had a couple dozen inetd processes listed - after following your directions (killall inetd, save on advanced features page), it cleared them up.  Here's inetd processes looked like before I cleaned it up:

: ps auxf|grep inetd
root    9936  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)
root   11918  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)
root   12053  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)
root   12139  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)
root   14063  0.0  0.2  9036  2212  ??  I     9:59AM   0:00.00 inetd: wrapping (inetd)
root   14273  0.0  0.2  9036  2212  ??  I     9:59AM   0:00.00 inetd: wrapping (inetd)
root   15252  0.0  0.2  9036  2156  ??  I    12:40PM   0:00.00 inetd: wrapping (inetd)
root   15405  0.0  0.2  9036  2156  ??  I    12:40PM   0:00.00 inetd: wrapping (inetd)
root   26621  0.0  0.2  9036  2156  ??  I    Mon08AM   0:00.00 inetd: wrapping (inetd)
root   26700  0.0  0.2  9036  2156  ??  I    Mon08AM   0:00.00 inetd: wrapping (inetd)
root   26859  0.0  0.2  9036  2156  ??  I    Mon08AM   0:00.00 inetd: wrapping (inetd)
root   26946  0.0  0.2  9036  2156  ??  I    Mon08AM   0:00.00 inetd: wrapping (inetd)
root   27194  0.0  0.2  9036  2156  ??  I    Mon08AM   0:00.00 inetd: wrapping (inetd)
root   56566  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   56602  0.0  0.2  9036  2208  ??  Is    9May12   2:20.76 /usr/sbin/inetd -wW -R 0 -a 127.0.0.1 /var/etc/inetd.conf
root   56912  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   57210  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   57256  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   57482  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   57582  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   57827  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   57842  0.0  0.2  9036  2112  ??  I    30May12   0:00.00 inetd: wrapping (inetd)
root   60346  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)
root   60609  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)
root   60900  0.0  0.2  9036  2156  ??  I    Mon09AM   0:00.00 inetd: wrapping (inetd)

@johnpoz:

When I think of  LAGG, I think of high speed connections - ie load balanced, your just using it in failover mode?

You don't really need to setup lagg for just failover, 2 connections with stp keeping one off would allow for failure of one of the nicks, etc.

LACP is Load Balancing, but when one link fails it continues service as a single link rather than dual

does nobody knows if can i force pptp vpn to work on a speciefied port not on 1723 default port…

Well if you disable the ftp proxy you would have to setup the manual stuff for access from outside, since outside users would not able to connect to your private IP in a active connection.  When they connect from source port 20 to the port your server tells them to connect to.  The ftp proxy opens this port and changes the IP from the private one to the public for you when the client connects.

If your not seeing it in a capture - could it be a name resolution thing?  How does your java app attempt to identify or verify this connection?

@costasppc:

You need manual outbound NAT for Asterisk to work properly.

I assume you meant "You need manual outbound NAT" … with static-port option enabled. Having looked into the subject of NAT + SIP, I would say that static-port isn't typically required (I've never had to enable it for either 2.0.1 or 2.1-BETA with various versions of Asterisk 1.8.x). In fact static-port can lead to other sorts of problems, e.g. read http://forum.pfsense.org/index.php?topic=45255.15

VoIP questions come up often in this forum, however it is nearly impossible to offer a universal guide that works for everyone. There are just too many combinations of factors involved e.g. NAT implementation, capabilities and configuration of SIP peers (i.e. VoIP software at your side as well as at your VoIP provider's), possibly enabled SIP ALG/proxy inside the ADSL modem, people enabling siproxd etc.

To debug VoIP issues, one has to look at packet captures of SIP traffic.

Oh, but thats what I need.  The destination IP is the WAN IP Address and the final resting place is on the LAN.

I got it to work. This is not the first time that I have had to do setup like this to get the Gafachi trunk working. I will be switching to a different provider as soon as possible since this is the second time they seem to have changed the setup on their end without notification and caused my phone system to go down, right in the middle of doing a lot of advertising.

Tobias,

you can create an outbound NAT rule for your DMZ subnet and check the 'Do not NAT' checkbox at the very top of that NAT rule.

Andreas

Can you show the contents of /tmp/rules.debug – or at least the line it's giving an error for?

And a copy of just that rule from inside config.xml (might need the alias that goes with it, too).

If you don't want to post them here, you can pm them to me or send them to jimp (a) pfsense (d) org.

This is becoming problematic. I though it would only happen once every few months, but my internet connection isn't very stable these days it seems and it just happened twice today.

I also noticed that asterisk isn't the only one who seem to never notice the connection was gone for a few seconds. I'm also connected to IRC and it will stay connected, but doesn't actually receive anything anymore until I reconnect it manually. I let it in that state for over 20 minutes and it never disconnected by itself(which is used to and should do).

What could be causing that in the router?

Thank you for your response Efonne,

To clarify:

-On the Outbound NAT tab (Firewall:NAT:Outbound:Edit):
Interface=LAN
Protocol=any
Source type=Any
Source port=Any
Destination type=Network
Destination Address=172.16.8.171/32
Destination Port=Any
Translation Address=Interface Address
Port=Any
Static-port=Not checked
No XMLRPC Sync=Not Checked

(Is it suppose to be like this? The above conf didn't work.) deleted

Edited: After changing the rule to manual config mode and saving, it worked.

Thank you very much.

SbKom

Hi,

I am wondering if you found a solution to this. I am facing the exact same problem.

Solved. I was overthinking it.
On nat rule sufficed. ON PF2 mapping port 1112 of the LAN2 on 192.168.3.1:1111.

Done.

Glad to hear it's resolved now.

This should however work without static port NAT as long as the NATed endpoint on your end is aware of its public NAT address (and obviously if the endpoint has NAT support built in).

Andreas

@podilarius:

The problem might be double NAT. If that is the case, it might be open on the pfSense FW, but is not being forwarded by the internet router. There is not enough information on your setup to really know.

I use PfSense as the router and modem if thats what you mean? I am not using the one you get from your ISP. Everything I have is in the set up in post one, I have no other router or firewall in-between except the switches as shown in the setup.
"INTERNET" is the fibre optics from my ISP (Not sure what you actually call it)