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

    No traffic, tunnels in the green

    Scheduled Pinned Locked Moved IPsec
    28 Posts 9 Posters 14.2k 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.
    • V
      Visseroth
      last edited by

      now getting Error: xx.xx.xx.xx give up to get IPsec-SA due to time up to wait.

      I've checked and double checked my information, it matches on both sides. The only thing different this time is that on Host A I'm using 10.0.0.2/24 for the remote subnet and on host B I'm using 192.168.0.3/24 for my remote subnet.

      1 Reply Last reply Reply Quote 0
      • V
        Visseroth
        last edited by

        Got the connection to come back up but now on my firewall with the ip address 192.168.0.0/24 I'm getting….....

        Oct 28 04:55:29 racoon: ERROR: couldn't find configuration.
        Oct 28 04:55:19 last message repeated 3 times
        Oct 28 04:54:49 racoon: ERROR: couldn't find configuration.

        1 Reply Last reply Reply Quote 0
        • V
          Visseroth
          last edited by

          Traffic is showing up on 10.0.0.1/24 coming from 192.168.0.1/24 through enc0 but not returning

          1 Reply Last reply Reply Quote 0
          • V
            Visseroth
            last edited by

            Nothing?

            1 Reply Last reply Reply Quote 0
            • F
              focalguy
              last edited by

              have you done any packet captures lately? I'd start capturing packets to see if they are arriving and not being returned or if they are not even arriving. Could the devices on one side of the tunnel have a different gateway that doesn't know about the route to the tunnel?

              1 Reply Last reply Reply Quote 0
              • V
                Visseroth
                last edited by

                OK, IPSec sucks, that's all there is to it, down with IPSec

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

                  Having the same basic problem myself, tunnels are up, but pings won't go through and am unable to load up web interface for pfsense2 from pfsense1. I checked the packet capture for the pinging and it shows the ping coming in and being sent back out but pfsense1 never receives the pings. I have IMCP traffic allowed, AH traffic allowed, and all traffic allowed on lan/wan/ipsec firewall tabs…..

                  1 Reply Last reply Reply Quote 0
                  • D
                    drade
                    last edited by

                    @htgtech:

                    Having the same basic problem myself, tunnels are up, but pings won't go through and am unable to load up web interface for pfsense2 from pfsense1. I checked the packet capture for the pinging and it shows the ping coming in and being sent back out but pfsense1 never receives the pings. I have IMCP traffic allowed, AH traffic allowed, and all traffic allowed on lan/wan/ipsec firewall tabs…..

                    I can add myself to this thread as well having the same symptoms as the individuals above. IPsec tunnels are presenting as connected but no traffic passes through, funny thnig is that the firewall log shows the traffic as "passed" even though nothing is actually going through.

                    These symptoms present themselves on both 1.2.2 and 1.2.3-rc3 releases. And to add a little bit more spice to the whole story i can connect fully to the LAN interface of the remote pfsense box just fine (attachments show 10.2.1.222 which is the LAN IP of the aforementioned pfsense box).

                    Telnet attempt to the local IP address of that remote subnet running nagios on the port 12489:

                    This is how it looks in the pfsense log:

                    Another SS of the CLI:

                    ICMP passed ?:

                    1 Reply Last reply Reply Quote 0
                    • D
                      drade
                      last edited by

                      Hello,

                      Please disregard my last post, clearly a PEBKAC problem (someone from the tech. dept. added a static route on all servers to the inexistent gateway … ah joy !).

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        jimp Rebel Alliance Developer Netgate
                        last edited by

                        You may also try to check "Prefer old IPsec SAs" under Advanced options.

                        I had a tunnel today to a different device (watchguard firebox) that was not stable (would just stop passing traffic, if it did at all) without that setting turned on.

                        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                        Need help fast? Netgate Global Support!

                        Do not Chat/PM for help!

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

                          Ok, I've narrowed down my problem to the AH/ESP settings…. If I use AH the tunnel connects but no traffic goes through, however, if I use ESP the tunnel connects and traffice goes through with no trouble. The problem here being, I have to use AH because we have to not only connect to our own routers but also to a 3rd party router which uses the the AH setting..... Any ideas on how to fix this?

                          1 Reply Last reply Reply Quote 0
                          • jimpJ
                            jimp Rebel Alliance Developer Netgate
                            last edited by

                            AH traffic is not encrypted, only authenticated. I would fix the device that supposedly requires AH, as otherwise you're sending all of this traffic with no protection.

                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                            Need help fast? Netgate Global Support!

                            Do not Chat/PM for help!

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

                              Unfortunately we can't dictate to the 3rd party how they should set up their VPN tunnel, they get to dictate to us what we have to set up in order to connect to them.

                              1 Reply Last reply Reply Quote 0
                              • B
                                bkm
                                last edited by

                                htgtech
                                You do know that you need to set up separate tunnels, right? The tunnels to your routers could have the ESP setting and the tunnel to the third party could use AH. I apologize if this answer is beneath you. I don't know anyone's experience level.

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

                                  I realize the need for seperate tunnels, as I have 5 tunnels already set up on the main router to go to the other routers. However, the problem still remains that the AH protocol is not allowing traffic which would still be an issue on the other tunnel to the 3rd party. Unless the problem is only with 2 pfsense routers trying to use AH.

                                  1 Reply Last reply Reply Quote 0
                                  • V
                                    Visseroth
                                    last edited by

                                    I just realized something. I am getting traffic from 192.168.0.0 to 10.0.0.0 but not from 10.0.0.0 to 192.168.0.0 which is how I want it. How can I change the order so that traffic from 10.0.0.0 can get to 192.168.0.0. If  I can get that traffic to flow then what I am trying to connect to should work as I can ping from 192.168.0.0 but not from 10.0.0.0

                                    1 Reply Last reply Reply Quote 0
                                    • V
                                      Visseroth
                                      last edited by

                                      I also just noticed that I'm getting a sendfromto failed error on 192.168.0.0

                                      " racoon: ERROR: sendfromto failed"

                                      1 Reply Last reply Reply Quote 0
                                      • V
                                        Visseroth
                                        last edited by

                                        Well in new news I setup a tunnel between me and another local location and it was working fine then went down. I brought the tunnels back up but again I can't get traffic through the tunnels.

                                        1 Reply Last reply Reply Quote 0
                                        • I
                                          ISCGDave
                                          last edited by

                                          @Visseroth:

                                          Well in new news I setup a tunnel between me and another local location and it was working fine then went down. I brought the tunnels back up but again I can't get traffic through the tunnels.

                                          Can I ask what version you have at both locations?

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