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

    Weird IPSEC tunnel issue.

    Scheduled Pinned Locked Moved IPsec
    15 Posts 4 Posters 5.9k Views
    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.
    • P
      pcdoc
      last edited by

      I originally opted to run pfSense over Monowall for the uPnp ability with my Xbox 360. However I have several tunnels open to client networks and have never had any problems running with Astaro but pfSense created a weird issue. My internal network is 192.168.2.0/24 and the remote network is 9.9.9.0/24. I can ping every machine in the remote network with no issue. However if I try to RDP to machines with IPs of 9.9.9.7 & 9.9.9.8 I cannot connect. It was so frustrating that I installed Monowall instead and have no issues as I described. I thought maybe it was a faulty install. So I redid the same setup on another box with pfSense and again it exhibited the same problem. Anybody have any clues? I would really rather run pfSense than monowall for the gaming abilities.

      The hardware being used:

      Box 1:
      ALIX 2c3
      512MB CF card

      Box 2:
      ALIX2c3
      512MB CF card
      Soekris VPN 1411

      Thanks in advance for any help provided.

      1 Reply Last reply Reply Quote 0
      • H
        hoba
        last edited by

        pfSense, other than m0n0wall, can do filtering inside of tunnels. Did you create appropriate rules at firewal>rules, ipsec tabs on both ends?

        1 Reply Last reply Reply Quote 0
        • P
          pcdoc
          last edited by

          The rules are set to allow any traffic out. As I said I can ping any machine though the tunnel with no issue. I can RDP to the following addresses with no problems: 9.9.9.2, 9.9.9.3, 9.9.9.4, 9.9.9.5, 9.9.9.6, 9.9.9.9. However I can not RDP to 9.9.9.7 or 9.9.9.8 but I can ping them. Why should pfsense block me from accessing those IPs with RDP and monowall have no issues whatsoever?

          1 Reply Last reply Reply Quote 0
          • H
            hoba
            last edited by

            I doubt that this is pfSense related. Maybe desktopfirewall on the host or something.

            1 Reply Last reply Reply Quote 0
            • P
              pcdoc
              last edited by

              It is definitely a pfSense problem. Nothing is changing on the remote side and thre is no client based firewalls on either the local or remote workstations. I am just swapping the boxes on my side one with Monowall one with pfSense, the remote endpoint is a Sonicwall 2040. They both have identical rules and configuration on fresh installs. Monowall no problem, pfSense big problem.

              1 Reply Last reply Reply Quote 0
              • GruensFroeschliG
                GruensFroeschli
                last edited by

                Have you tried setting the static port option?
                I had a problem where i couldnt connect to VNC clients without the static port.

                Also before you try a port redirect: is the direct port-forward working?
                Is the firewall rule correct for the port-forward?
                NAT is before the firewall. So the rule has to allow the port which is on the client open and not the port which is open on pfSense.

                EDIT: d'oh i kind of totally missed that the traffic is over the IPSEC tunnel ^^"

                We do what we must, because we can.

                Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                1 Reply Last reply Reply Quote 0
                • P
                  pcdoc
                  last edited by

                  There is no need for a static port or NAT through an IPsec tunnel. The reason for using a IPsec tunnel is to secure two networks together. In the process of doing so both endpoints know of the remote private networks and can route traffic destined to the remote network via the tunnel. Again the remote side is running a Sonicwall box and I have two boxes to test with on my side, both of which are identical with the exception that one is running monowall the other pfsense. Both establish the tunnel properly both have identical rule sets but the pfsense will refuse to send or receive traffic on only those two IPs that I can tell so far. I haven't tried to connect to more than the 10 IPs I have tested there. There are 70 units there and I would guess if it is acting up for 2 out of the 10 I have tested thus far there will probably be more that are being blocked. It just so happens that those 2 are vital servers that I need to get too on a daily basis.

                  1 Reply Last reply Reply Quote 0
                  • H
                    hoba
                    last edited by

                    Check pftop from the shell and/or disgnostics>states to see what happens to connections to these hosts.

                    1 Reply Last reply Reply Quote 0
                    • P
                      pcdoc
                      last edited by

                      I'm surprised, no one has a clue what is causing this??

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

                        Same problem here.
                        After resetting the tunnel it works for a while and then dies again.
                        Hope to see a solution soon

                        1 Reply Last reply Reply Quote 0
                        • H
                          hoba
                          last edited by

                          @hoba:

                          Check pftop from the shell and/or disgnostics>states to see what happens to connections to these hosts.

                          If you don't know what I ask you for and provide more info I can't help you  ::)

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

                            Hi Hoba and all the others….

                            I think i got the solution:

                            Check you´re WAN´s MTU on both sides.

                            In my case i use 2 different ISP´s:
                            1st ISP: T-Systems BAIP 1,3 Mbit synchron permanent link MTU 1500
                            2nd ISP: BREISNET ADSL 800 synchron PPPOE link MTU 1450

                            I just put a MTU of 1450 @ the BAIP WAN and RDP works.

                            Please let me know if this helps.

                            Thanks Chris

                            1 Reply Last reply Reply Quote 0
                            • H
                              hoba
                              last edited by

                              Actually if this is an mtu problem we might already have fixed it in an upcoming version where pfSense will deal a bit differently for mtu's for traffic inside ipsec tunnels.

                              http://cvstrac.pfsense.org/chngview?cn=22244

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

                                Ok nice to hear but what is now?
                                I need a fast solution. because unfortunatly it is not a stable solution i posted before.

                                It works for some time but everytime the ISP changes the routes behind it goes down.

                                1 Reply Last reply Reply Quote 0
                                • H
                                  hoba
                                  last edited by

                                  Try to lower the mtu of the clients that are not working.

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