IPsec: Mobile Clients

[Tripple_Delta]

Now that my IPsec connection works I'm bumping into the next problem.
Mobile clients get an IP but that's it. No ping to the LAN, no internet access, nothing. I can only ping myself.

I've been reading a lot about this. Looks like I'm not the only one but so far no solution for me.

Anyone can point me in the right direction?

[bartjsmit]

Did you read the documentation? https://docs.opnsense.org/manual/how-tos/ipsec-road.html

Bart...

[Tripple_Delta]

Yes, this is the configuration I'm trying to set up.

[franco]

Are the IPsec interface firewall rules set to pass for the client(s)?

[Tripple_Delta]

Very strange behavior on the web interface. The IPsec tab in the firewall rules was not visible. I've seen this before, probably making a mistake somewhere.

No idea what the problem was but now it seems to work. I'm going to try to reverse my settings in order to find out what went wrong.

Thanks for the support.

[franco]

Hi Tripple_Delta,

Hmm, are you on a version prior to 16.7.5? The IPSEC rules tab disappearing was a subtle bug in 16.7, but never enough for people to report it so I found it by accident and fixed it recently.

If you are on 16.7.5 and this is still happening please let me know how to reproduce and I'll take a look.


Cheers,
Franco

[Tripple_Delta]

Hi Franco,

I'm running the latest version but unable to reproduce it at the moment.

Versions    OPNsense 16.7.5-amd64
FreeBSD 10.3-RELEASE-p9
OpenSSL 1.0.2j 26 Sep 2016

[franco]

ok, so far so good 

[tofflock]

Hi

I have a very similar problem with the tab for the IPsec interface coming & going (in FW rules).
I have two FWs (UK-FW & FR-FW) both running the latest:

OPNsense 16.7.7-amd64
FreeBSD 10.3-RELEASE-p11
OpenSSL 1.0.2j 26 Sep 2016

Both are patched up-to-date. The UK-FW has a DHCP WAN interface, LAN & OPT1 interfaces
The FR-FW has a PPOE WAN interface with just a LAN interface.
The two FWs are "connected" via an IPsec VPN

The UK-FW shows an IPsec tab in the FW rules.
The FR-FW does NOT show an IPsec in the FW rules.

Also:
If I select the (for e.g.) the LAN tab in FW rules, and look in the dropdown list to select the interface, then:

on the UK-FW the IPsec interface is listed, but
on the FR-FW the IPsec interface is NOT listed

This is consistent with the absence of the IPsec tab in the FW rules on FR-FW.

There was a short time when I was configuring the FR-FW a few days ago, that I saw the IPsec tab on the FW rules page, but then it disappeared.

What information would you like from me to try and identify why I have this anomaly?

Regards,

Peter

[tofflock]

Update to my missing IPsec tab

I've taken a look through some of the PHP code and that prompted me to go and examine my config.xml files.
I found that in the <interfaces>...</interfaces> section that:

In the config file on UK-FW, there is a section for <enc0>...</enc0> , whilst
in the config file on FR-FW, there is NO section for <enc0>...</enc0>

I have identified, by searching the automatic backups, where the <enc0> disappeared, but I have not yet identified why it was deleted.

By the way, the IPsec VPN is still working between the two FWs!
I see that the enc0 interface is still referenced in the FW rules section on the FR-FW.

Running ifconfig -a on both FWs reports that enc0 exists, and the details that ifconfig -a reports are identical on both FWs.

[tofflock]

Update 2 to my missing IPsec tab

I finally found the diff section in the Webgui and it shows the following:

Code: [Select]

Configuration diff from 11/4/16 10:37:47 to 11/4/16 10:43:54
--- /conf/backup/config-1478252634.8361.xml 2016-11-04 10:43:54.836514000 +0100
+++ /conf/backup/config-1478253523.7622.xml 2016-11-04 10:58:43.762601000 +0100
@@ -267,14 +267,6 @@
       <ipaddr>192.168.200.100</ipaddr>
       <subnet>24</subnet>
     </lan>
-    <enc0>
-      <internal_dynamic>1</internal_dynamic>
-      <enable>1</enable>
-      <if>enc0</if>
-      <descr>IPsec</descr>
-      <type>none</type>
-      <virtual>1</virtual>
-    </enc0>
   </interfaces>
   <dhcpd>
     <lan>
@@ -815,8 +807,8 @@
   </widgets>
   <revision>
     <username>root@192.168.200.80</username>
-    <time>1478252267.1359</time>
-    <description>/services_dyndns_edit.php made changes</description>
+    <time>1478252634.8365</time>
+    <description>/vpn_ipsec_phase1.php made changes</description>
   </revision>
   <cert>
     <refid>57304e494c407</refid>

I seem to recall that I was having problems getting the VPN to connect.  I detected an entry in IPsec log file (on the FR-FW end I believe - but not certain) which said something along the lines of "No shared key detected".  There was (is) a shared key, and I found that accessing the webgui page for phase 1 and pressing "Save" at the bottom, seemed to help getting both ends of the VPN to cooperate and set up the VPN successfully.  I think that is the end of what I can identify and remember for the moment.

Peter

[franco]

Simply saving a phase 1 or phase 2 entry on FR-FW should really bring the interface up by injecting the identified missing bits into the config. I know we had this latent bug in there since maybe 16.7.2 until 16.7.5. Could it have been one of those that it was first configured on? Also, is this an XML-synced setup?

[tofflock]

Hi Franco

Both firewalls were installed fresh from the same OPNsense-16.7-OpenSSL-vga-amd64.img file. (Pedantically, it wasn't actually the same file, but I've just computed the sha256 checksums on the (img) files I used, and they're identical.)

They both created their own config.xml file and there is no sharing or synchronisation between the config files on the two systems.  I didn't even restore backups from their predecessors as the hardware I was running until a couple of weeks ago was 32-bit, whereas  the new HW supports 64-bit. 

You said

Simply saving a phase 1 or phase 2 entry on FR-FW should really bring the interface up by injecting the identified missing bits into the config.

The interface is up, according to ifconfig, and the VPN is working - traffic is passing as intended.  What alerted me to the problem was the missing IPSec tab on FW rules page.  After that I found the <enc0> section missing from the config.xml file.

Looking at the up-time for FR-FW, I don't think it's been rebooted since 10:34 on 4-Nov.  According to the Config diff I posted, the <enc0> section was present at the last boot.

Which way next?

Cheers

Peter

[tofflock]

Hi Franco

I believe I've found an inconsistency in the web interface for IPsec.

Following your statement:

Simply saving a phase 1 or phase 2 entry on FR-FW should really bring the interface up by injecting the identified missing bits into the config.

I thought I'd take a look at the php code (I'm not a php expert) but I regret I didn't make much progress.  I then did some tests just enabling & disabling the phase 2 entry to see what the results were.  I chose enable/disable as the least invasive/destructive thing that I thought I could do without damaging my working FW.

My FW config has one entry for phase 1, and one entry for phase 2 in the IPsec configuration.

If one starts with no <enc0> section in the <interfaces> section in config.xml AND the phase 2 entry is disabled, then:

• If one enables the wanted (only, in my case) phase 2 entry by pressing the enable button (Grey) (triangle in a square - TIS) on the vpn_ipsec.php page, then there WILL be an <enc0> section in the config.xml file (*1) (*2)
• If one enables the wanted phase 2 entry by pressing the edit button, and on the vpn_ipsec_phase2.php... edit page,  removing the tick in the disabled box, and then pressing save, there WILL NOT be an <enc0> section in the config.xml file (*1) (*3)

*1   The "Apply changes" button is also pressed
*2   The IPsec tab is then visible on the FW rules page (firewall_rules.php)
*3   There is NO IPsec tab on the FW rules page (firewall_rules.php)

There are also the same two ways to disable the phase 2 entry:

• Pressing the Green TIS button, and then accepting the changes
• Entering the edit screen for the pahse 2 entry and ticking the disable box, saving the configuration and accepting the changes

Both these methods remove the <enc0> section from the <interfaces> section.

Phase 1 Enabling
If one starts with no <enc0> section in the <interfaces> section in config.xml AND the phase 1 entry is disabled AND the phase 2 entry is enabled, then the behaviour is similar to the enabling of the phase 1 described above. One only gets an <enc0> section in the config.xml file if the (Grey) TIS button is pressed.  Enabling phase 1 on the edit page leaves the config.xml file without an <enc0> section.

I hope this helps you work out where the problem is in scenario 2. above.  If I get another opportunity to look at the php code, I will, but it can't happen for a few days.

Best wishes,

Peter

[tofflock]

Hi Franco

I've just bitten the bullet and upgraded my FR-FW to V17.1.2.  UK-FW is still running V16.7.14_2.  The inconsistency that I reported on 2016-11-14 has been fixed in V17.1.2

This means that if one enables the phase 2 entry by editing and removing the tick for disabled entry, the <enc0> section in the interfaces section in config.xml will be created correctly.

This bug can therefore be marked as fixed in V17.1.2.

Hope this helps,

Peter