-
@SeaMonkey said in No Site-to-Site VPN after upgrading CE from 2.6.0 to 2.7.0:
Just going to chime in to say this was my misconfiguration that worked in 2.6 and didn't work in 2.7. Thanks for the hints.
What's the config, then? 3DES? https://docs.netgate.com/pfsense/en/latest/releases/2-7-0.html#general
-
Mode: Peer to Peer ( SSL/TLS )
Data Ciphers: AES-256-GCM
Digest: SHA256
D-H Params: 2048 bitsedit To be more specific, DNS domain overrides were failing much more frequently in 2.7. Removed the redundant static routes and DNS resolution across the VPN was instantaneous whereas even while working in 2.6, it seemed to take several seconds.
-
And so far I haven't seen anyone that has followed my troubleshooting suggestions from earlier in the thread:
-
J jimp forked this topic on
-
@jimp I have since rolled back to 2.6.0. I am willing to share config.xml files from before rolling back with netgate. My hardware is supermicro X10SDV-TLN4F which is probably what s in Netgate 1541 1U. For obvious reasons, I would not post such files in the forum.
-
I'm holding off upgrading to 2.7 from a working 2.6 config until this issue(s) is/are resolved. I've been following since the start and as a developer myself I was a little surprised the initial redmine ticket by @michaelschefczyk was closed so quickly. Clearly multiple people are having issues with site to site VPNs after the 2.7 upgrade.
Clearly something has changed. Even if everyone's issue(s) turns out to be a misconfiguration that somehow worked in 2.6 but no longer in 2.7, it would be good to know and have documented why this is no longer the case. Just like the PHP upgrade warning to uninstall packages prior to upgrade.
If people are willing to share their configs, is this something that can be run up in a dev/test environment by Netgate?
-
@matt84 said in No Site-to-Site VPN after upgrading CE from 2.6.0 to 2.7.0:
I'm holding off upgrading to 2.7 from a working 2.6 config until this issue(s) is/are resolved. I've been following since the start and as a developer myself I was a little surprised the initial redmine ticket by @michaelschefczyk was closed so quickly. Clearly multiple people are having issues with site to site VPNs after the 2.7 upgrade.
It was closed because there was no evidence it was a bug or anything we could determine programmatically, and there still isn't.
Clearly something has changed. Even if everyone's issue(s) turns out to be a misconfiguration that somehow worked in 2.6 but no longer in 2.7, it would be good to know and have documented why this is no longer the case. Just like the PHP upgrade warning to uninstall packages prior to upgrade.
So far no two people have had the same problem, but most people haven't given us enough detail to determine what their problems might be. People keep jumping into the thread saying they have the "same issue" when it most likely isn't, but trying to diagnose them all in one thread is not viable.
If people are willing to share their configs, is this something that can be run up in a dev/test environment by Netgate?
It depends on the complexity of the setup. We can lab some things but completely replicating someone's multi-site VPN infrastructure is more likely to have problems from the lab setup being wrong vs replicating the user's original problem.
-
J jimp locked this topic on
-
I'm locking this thread for now because it really needs to be a separate thread for every different person here, and people keep lumping their issues together.
I'll try to fork off some of the different ones I can isolate, but feel free to start new threads separately if you choose.
Please keep these discussions separate and do not put your own diagnostic info in someone else's thread even if your symptoms sound similar.
@michaelschefczyk If you want to submit your configuration files to TAC, mention my name and this thread. TAC can't help you directly but they should be able to get the files to me privately.
I'll unlock this thread after I get things separated if I can.
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp forked this topic on
-
J jimp unlocked this topic on
-
OK, I split each different person's troubleshooting posts off into separate threads. It's likely I missed some or they're missing some context now, but having them separated will make following individual problems much less confusing.
Please keep posts in this thread relevant to OP's specific problem and keep meta discussion and separate problems in their own posts/threads and not here.
Thanks!
-
@jimp I did submit four configuration files and a brief explanation under ticket number 1773311411. This took some time, because I wanted to be physically present at each side of the connection when changing and reinstating the configuration. Any feedback would be most welcome!
-
@michaelschefczyk
I've update my Topic and my issue was solve, Please check it out if it can help you a bit. -
I finally had some time to review the configurations you submitted and I found a number of configuration errors, some of which could combine to make it work on 2.6.x but fail on 2.7.x
- There is a conflicting IPsec tunnel with a P2 for S10m LAN <-> B72m LAN
- Client on B72m has OpenVPN tunnel network filled in and it shouldn't
- S10m has route to client subnet (192.168.12.0/24) on ovpns3 (port 1196), and also a conflicting entry on the ovpns4 (port 1197) server, in addition to the correct entry on Server 5.
- You cannot have the same remote network on more than one server entry
- Whichever one starts first will end up with the route in the table, and no others!
- There is a rule in the ruleset on S10m which can't be resolved
- "# destination address is empty. label "USER_RULE: IPsec S10-B72""
- In config.xml this references OPT8 which doesn't exist
- This is causing the VPN traffic to fall through to the next rule which has a gateway set, which will bypass the VPN
- There is a similar broken rule on B72m "IPsec S10-B72"
So to fix it, you should:
- Disable or delete the IPsec tunnel if you want to use OpenVPN, otherwise IPsec will be grabbing the traffic in its kernel policy and it won't ever reach OpenVPN.
- Might need to flush the SPD entries or reboot to ensure the policies are removed.
- On S10m, Remove Remote Network 192.168.12.0/24 from Server 3 (S10-B72 CATV) and Server 4 (S10-B72 DSL)
- Edit/Save Server 5 (s2s) afterward to ensure it gets its route in the table properly.
- Fix the broken firewall rules so they have the proper destination (Use B72 alias on S10, and use S10 alias on B72)
-
@jimp Thank you very much! Due to limited reachability of the other end during the summer holiday period, I will try this in the second half of August! Michael
-
Hi.
I had a similar problem. It started after I upgraded to 2.7.0.
Several OpenVPN Peer to Peer connections with Shared Keys stopped working. SSL/TLS were still operational.After collecting all informations i found out:
- the tunnel connections are functional, but i could not communicate from the Servers side (where the OpenVPN Server is) LAN.
- the clients are on pfSense 2.3.4 most (because of older hardware)
- i could reach the clients LAN from the pfSense Server shell
- because of multi WAN the tunnels are bind to LAN
The solution was:
- add firewall rules on LAN with source LAN NET and Destination the Client side LAN network and choose the Default Gateway under advanced.