2

I have just installed pfSense on a PC Engines APU1D4 to evaluate as an alternative to a Soekris 5501 + OpenBSD based setup, I have a PPPoE WAN configuration.

The pf rules, NAT and PPPoE configurations appear to be the same as my OpenBSD box but some websites fail to load such as twitter.com. I thought it might be to do with the WAN MTU, I've tried changing this to 1492 and 1452 but it makes no difference, I've also followed all the suggestions here to no avail. https://doc.pfsense.org/index.php/Unable_to_Access_Some_Websites

Packet capture of entire conversation here: https://dl.dropboxusercontent.com/u/249827/packetcapture-twitter-wan.cap https://dl.dropboxusercontent.com/u/249827/packetcapture-twitter-lan.cap

Any ideas what could be going on?

Phil
  • 21
  • 1
  • 3

1 Answers1

1

Not getting far enough to be MTU-related. You're sending a SYN, getting a SYN ACK in reply, then RSTing the connection rather than completing the TCP handshake. Something is aborting the connection. That's an unusual circumstance, nothing about that suggests a specific cause. Looks like that capture reference point is your WAN, try the same on LAN to see where the RST is being initiated.

Chris Buechler
  • 2,998
  • 14
  • 18
  • Thanks, I've edited the question and added added both LAN and WAN captures. – Phil Aug 26 '15 at 04:36
  • The new captures are much different from the first. Here it completes the full TCP connection no problem. It has the same traffic WAN and LAN side. No network or firewall-related issues there. You're now getting content type alert 21, decryption failed. That's a problem of some sort with the client or the server. – Chris Buechler Aug 27 '15 at 05:42
  • In the first case I used the Safari web browser to access https://twitter.com and the browser just waited indefinitely. – Phil Aug 27 '15 at 09:31
  • [comment editing timed-out] For the captures above I used Firefox and it came back with an SSL certificate error. This doesn't occur with my old OpenBSD router/firewall so I assumed the new setup is somehow causing invalid packets rather than it being a genuine SSL issue. – Phil Aug 27 '15 at 09:38
  • It's definitely something outside the firewall given the same traffic on WAN and LAN. – Chris Buechler Sep 02 '15 at 02:51