ok, thank You very much !

Tom

Depends on traffic rate in pps not Mbps, and the hardware you have. That sounds roughly normal depending on specifics.

That last capture is much different, more like what you showed in the text output, which shows the behavior varies. Why isn't clear. What the last one shows is your client sends the SYN to open the connection, it gets a SYN ACK in response, and then it RSTs the connection. In more plain English, basically your client starts the TCP connection, the 10.0.0.50 device responds back for the next step of the handshake, and then your client says "no, close that connection". Then your client sits there for 3 seconds and repeats the exact same process. After that, it sits there for 6 seconds and repeats again.

The order is as described, but the timing is such that I seriously doubt the client gets the SYN ACK before it sends back the RST. There is around a half ms between the SYN ACK and RST, which is far too short of a window for the client to have gotten the SYN ACK, so it seems more like the client sends then SYN, and about 10 ms later, sends the RST. The two retries have 1 ms between the SYN and RST.

I have no idea why your client would be behaving that way, but that's the issue. Firing up Wireshark on the host itself, in the capture options put in a filter for "host 10.0.0.50" on the OpenVPN interface, and see what you get at that point would be my next troubleshooting step.

Sorry I edited while you were typing!
I'll read your other thread.

Steve

you can't do that. installing packages locks things and you can't load other pages, you have to wait for the install to finish.

You have to do that by IP, need a DHCP reservation on that MAC if you're going to use DHCP on it.

I'm seeing an MTU issue after upgrading from 1.2.3 to 2.0.  I 'fixed' this by editing

/var/etc/pptp-vpn/mpd.conf

and adding:

set link mtu 1396

Then, killing the mpd process and restarting it:

/usr/local/sbin/mpd4 -b -d /var/etc/pptp-vpn -p /var/run/pptp-vpn.pid -s pptps pptps

That's not a pfSense 'solution' but perhaps others here could try it to see if our problems are the same?

This wasn't necessary before, so I'm wondering if defaults are different, path MTU discovery is somehow broken, etc.  BTW, I read that XP's pptp client requires 1396, so that's what I set for a compatibility floor.

The paid version of Kiwi syslog daemon can forward log records to another syslog server but I don't know if it can do that at the same time as logging the messages itself.   You might need to have two paid copies of Kiwi as well.

EDIT:  Having read the whole of the link below, I see that you don't need the paid version unless you want to spoof the original IP address.

http://www.kiwisyslog.com/help/syslog/index.html?action_forward_to_another_host.htm

~~I don't have the full version but you get 30 days of full function with a trial copy.  ~~It does only run on Windows though.

Good idea, that's very simple. Thanks!

I am pleased to report that I have discovered a solution. Thanks to everybody for eventually pushing me towards a solution!

In the end, this issue was caused by a configuration in the physical network that VMware did not like and, in fact, all VMs were suffering from poor network performance.

More specifically, the LAN side of the host system was running a teamed connection using 802.3ad protocol. This really served no purpose other than for my own vanity.The solution was simply to take apart this teamed link and run the gigabit ethernet ports individually while disabling all unnecessary adapters and services. I also followed as many recommendations as I could in the following document that my hardware allowed: http://www.vmware.com/pdf/ws7_performance.pdf

Again, thanks to everybody that pitched in on this problem and pushed me in the right direction, it is greatly appreciated!

Depends on how your ISP handles that. It probably dynamically assigns the PPPoE address (your WAN address) and routes your static IPs there. So you just need to set them up as Other VIPs and configure your NAT accordingly as desired.

It's a screwy way to block a connection, but that device is without question blocking the connection, it has nothing to do with your firewall. Off-subnet access being rejected is the most likely cause.

@stephenw10:

Since that's shown as a linked port forward I assume you have a firewall rule in place. Are you seeing anything in the firewall logs?

Steve

I don't know since all filter logs change so fast … anyway it was my fault ... had to connect to an external vpn server first then tried to connect via ssh to my host and it worked. Sorry for the trouble. Strangely though I hadn't to do this when using the Zyxel router ...
Connecting to my WAN IP address with a PC from the LAN directlly (i.e. not by using an external vpn) results in a connection timeout.
Thank you for your support stephenw10 ;)