Messages

16

15.1 Legacy Series / Re: [SOLVED] IPsec and TCP flows

« on: May 02, 2015, 03:30:30 pm »

Hi Ad,

I'll try it out today. Since the device is already in production, how do I revert to the previous kernel if it doesn't work? I think it is 15.1.9.1 with NoPatches.

17

15.1 Legacy Series / Re: [SOLVED] IPsec and TCP flows

« on: April 21, 2015, 09:14:49 pm »

Yes, thank you very much for the time you spent to troubleshoot this.

I'd just like to add that I installed today OPNsense x64 as a Hyper-V virtual machine and set up some VPN tunnels. The issue did not occur and everything works as expected. So it remains unknown why it is only present on the hardware appliance.

18

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 19, 2015, 12:48:27 pm »

I think there is some convergence time after the tunnel is established until the times reach the normal values of 3-4ms. This was the case with both machines I tested (the hardware appliance and the box I installed OPNsense on).

I'll send you an e-mail today to schedule a test with you tomorrow.

19

15.1 Legacy Series / Router-originating traffic for IPsec tunnel

« on: April 19, 2015, 02:14:56 am »

I need to configure my DNS forwarder with two domain overrides in order to send DNS queries to different DNS servers depending on the domain in the query (conditional forwarding). Each of these DNS servers is in a separate intranet which is connected to the OPNsense router using 2 VPN tunnels - one is OpenVPN and one is IPsec. The forwarding for the DNS names in the intranet connected via OpenVPN works great - the names are resolved as expected. However this is not the case with the names for the other (IPsec-based) connection.

The problem is that the router itself can send traffic into the OpenVPN tunnel bit cannot send into the IPsec tunnel (devices behind the router can communicate with both intranets without problems). I verified this using PING from the router. No firewall rules are configured to prevent this. I suppose this may be caused by the fact that the OpenVPN tunnel is a Point-to-Point tunnel and in the routing table the remote subnet is routed via the OpenVPN interface (ovpns1). No such entry exists for the IPsec subnet - it is routed via the WAN which is kind of awkward but works for devices behind the router. Is there a way to enable the router itself to send packets into the IPsec tunnel like with OpenVPN? Maybe it's a BSD issue, not OPNsense, but anyway. Actually, OpenVPN is so much easier and flawless than IPsec, I'd always prefer to use it, but unfortunately it all depends on the other endpoint...

20

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 19, 2015, 01:42:25 am »

So, finally, I was able to produce the video. Now you can watch the entire process - initial configuration of OPNsense, then IPsec and two tests - with Remote Desktop connection and SSH (10 minutes in total):

https://www.youtube.com/watch?v=1l4IJ60CTpw (Switch to HD for a clearer video. Part of the GUI is not in English but that should not be a problem).

Before I did that I changed the network port with one of the unused as you suggested and there was no change, the issue persists. However I was not able to install the x64 edition on my test computer as the CPU is not 64-bit capable.

Have a look at it when you have time and there's no problem to schedule a tunnel test with my side when you're available. Thanks again.

21

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 17, 2015, 01:17:59 am »

Today I installed OPNsense on a desktop PC with 2 Ethernet cards and tested my VPN using the exact same parameters (and ISP lines). The issue DOES NOT occur. I used the x86 image however and I see that the device is running x64. I'll check whether the Pentium 4 CPU I used supports 64-bit to test with it. I'd like to try this before recording the video.

22

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 15, 2015, 04:16:03 pm »

The other endpoint was running:

2.2.1-RELEASE (i386)
built on Fri Mar 13 08:16:53 CDT 2015
FreeBSD 10.1-RELEASE-p6

However it happens regardless of the other device - we have Cisco ASA, Lancom, Linksys and Cisco RVS 4000.
I tested yesterday on another site (using a completely different Internet connection) by building the configuration from scratch. I established the VPN from my home to the office (which runs Linksys RV082). The issue occurs exactly in the same manner. This time I also tried SSH and it's the same experience, the only difference being that SSH can't overcome the problem and doesn't reconnect, so I get "Software caused connection abort" after about 30-40 seconds. On Friday I'll record everything in a video and get back.

23

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 14, 2015, 07:50:36 pm »

Removing one of the WANs didn't change anything. What is more, I restored to factory defaults and used the wizard to configure the LAN interface and one of the WANs. Then I created one IPsec tunnel and the issue is still there. So, Multi-WAN is not causing it. It's not only Remote Desktop, I tried to copy some files using SMB (Windows File Sharing), the transfer doesn't start at all - network error. I noticed that the issue is caused by packets not being sent TO the other endpoint - I observed a clock ticking in a RDP session and the second hand on the clock didn't stop moving while I was unable to do anything in the session after which it just reconnects and this repeats every 30 seconds.

Now I'm taking the device with me at home and will test a tunnel to the old router that OPNsense is supposed to replace. If someone wants to help me further troubleshoot this, I'm ready to record all the steps in a video to show what I am doing and what exactly happens.

24

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 13, 2015, 08:11:23 pm »

Thanks for testing it, I'll remove one of the WAN interfaces and the associated firewall rules and see if it helps. If it doesn't, I'm restoring factory defaults and starting from scratch with one WAN and one tunnel.

25

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 12, 2015, 01:44:33 pm »

The problem is at my side for sure as this happens with each of the 5 tunnels I tested. The endpoints are different devices and the connection is OK when I switch the OPNsense router with another one. So it may or may not be the IPsec component that is at fault but the whole configuration as a whole.

26

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 10, 2015, 05:50:47 pm »

I tested with only one IPsec tunnel (the other 6 configured but disabled) and the issue still persists. I have sent the configuration to Ad per e-mail as requested. If anybody else wishes to test, I can provide it, just send me a PM.

27

General Discussion / Re: Cannot enable topic reply notifications

« on: April 06, 2015, 03:45:41 pm »

Thanks, it's there now.

28

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 06, 2015, 03:42:08 pm »

All right, I think I'll be able to test that in the next 2 days as I need to do that outside of business hours. I'll report back when I'm ready.

29

General Discussion / Re: Cannot enable topic reply notifications

« on: April 06, 2015, 12:07:25 am »

Indeed, there's no such a Notify button, I think I looked everywhere. The option In the profile may work, however I turned it on only after I've posted a topic already and it seems it didn't apply to the posted topic, only to new ones. Anyway, it would be convenient if the button to subscribe was available in each topic.

30

15.1 Legacy Series / Re: IPsec and TCP flows

« on: April 05, 2015, 08:28:08 pm »

Out of 7 configured tunnels, 5 were active at the time of testing and they all experience this issue. I think I haven't tested with one tunnel only, but I believe this shouldn't be a consideration. By config.xml, do you mean that I can extract the VPN connection profile somehow and send it to you? Or just to prepare a file with the VPN parameters so that you can test with the same Phase1/2 parameters? Or maybe the whole configuration of the device? Thanks for engaging into this problem!

By the way, this is the device if it matters.