Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Conection problems to websites using ssl/tls and vpn on pfSense bridge firewall

    Firewalling
    2
    5
    2.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      giorgiolago
      last edited by

      Hello friends. I'm using the forum because I do not know what to do.
      I have a pfsense server operating in bridge mode + firewall filtering a 100Mbits Link Fullduplex, what is happening is that sites that use SSL / TLS just does not open at all, it happens to home banking websites (www.bb.com.br www.caixa.org) and hotmail, another problem is that ipsec vpns keep falling or staying slow. I've done all the tuning presented here:
      https://calomel.org/freebsd_network_tuning.html
      But without success, something is happening that ssl / tls connections are intermittent.
      My server has a 2.93GHz cpu core i5 + 8GB + NC382T NIC

      1 Reply Last reply Reply Quote 0
      • C
        Cedus
        last edited by

        Hi!

        I have exact the same problem. Tested with two pfSense 2.1 machines. One with Intel E6000, 2GB RAM, 3Com 905TX NIC & Realtek 8139 NIC; the other machine with Core2Duo E7200, 4GB RAM, Intel Pro 1000 NIC & Realtek. HTTP ok, but HTTPS websites won't show up in IE/Chrome. BUT: from Linux it happens sometimes, that I can connect, although slow.

        greets

        1 Reply Last reply Reply Quote 0
        • C
          Cedus
          last edited by

          Hi again!

          Murphy's law: 5min after posting, I found the solution: I did filtering on both incoming and outgoing bridge-interface => bad for HTTPS (don't know why yet), but editing the system tunables to the following:

          net.link.bridge.pfil_onlyip = 1
          net.link.bridge.pfil_member = 0 (was 1 with faulty config)
          net.link.bridge.pfil_bridge = 1

          and deleting all rules from the interfaces which are members of the bridge and merging this rules into the bridge-interface only finallly solved this weird problem. As stated above, I don't know if it's a feature or a bug, but having a single ruleset on the bridge-interface works like a charm.

          1 Reply Last reply Reply Quote 0
          • G
            giorgiolago
            last edited by

            @Cedus:

            Hi again!

            Murphy's law: 5min after posting, I found the solution: I did filtering on both incoming and outgoing bridge-interface => bad for HTTPS (don't know why yet), but editing the system tunables to the following:

            net.link.bridge.pfil_onlyip = 1
            net.link.bridge.pfil_member = 0 (was 1 with faulty config)
            net.link.bridge.pfil_bridge = 1

            and deleting all rules from the interfaces which are members of the bridge and merging this rules into the bridge-interface only finallly solved this weird problem. As stated above, I don't know if it's a feature or a bug, but having a single ruleset on the bridge-interface works like a charm.

            Cedus thx for your reply, if i set net.link.bridge.pfil_member = 0  my firewall drop many capackets and my latency grow up ! :(

            1 Reply Last reply Reply Quote 0
            • G
              giorgiolago
              last edited by

              Solved ! I'm disable this options :
              System > Advanced > Networking :

              * Disable hardware checksum offload
                * Disable hardware TCP segmentation offload
                * Disable hardware large receive offload

              And reboot  and use cedu's confs:

              net.link.bridge.pfil_onlyip = 1
              net.link.bridge.pfil_member = 0
              net.link.bridge.pfil_bridge = 1

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.