IPSec from remote to LAN connections are dropped

iamzam

I am seeing similar problems, starting yesterday, where I can connect from local to remote over ipsec but it will drop after a small period of time, it always seems to be around 30 to 35 seconds.

This was on both the latest 2/5 snapshot and the earlier one from 2/5

2.1-BETA1 (amd64)
built on Tue Feb 5 20:25:07 EST 2013
FreeBSD 8.3-RELEASE-p5

ggzengel

Firewall rules on ipsec not working.
Only icmp passes.

eri--

Canyou try gving the value 0x0002 to the tunable net.enc.in.ipsec_filter_mask?

ggzengel

That's it.
It's working again.

Can you explain?

eri--

What kind of tunnel you have?
Can you show your configuration?

bardelot

@ggzengel:

Can you explain?

The sysctl variable defines what will be passed to the firewall.

From the corresponding man entry [1]:

For the incoming path a value of 0x1 means "before stripping off the outer header'" and 0x2 means "after stripping off the outer header''.

[1] http://www.freebsd.org/cgi/man.cgi?query=enc&apropos=0&sektion=4&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html

ggzengel

The sysctl variable defines what will be passed to the firewall.

What has changed that it is necessary?

What kind of tunnel you have?
Can you show your configuration?

Nothing special.


		 <phase1><ikeid>1</ikeid>
			<interface>wan</interface>
			<remote-gateway>pfsense.hq2</remote-gateway>
			<mode>aggressive</mode>
			<myid_type>fqdn</myid_type>
			<myid_data>hq1</myid_data>
			<peerid_type>fqdn</peerid_type>
			<peerid_data>hq2</peerid_data>
			 <encryption-algorithm><name>aes</name>
				<keylen>128</keylen></encryption-algorithm> 
			<hash-algorithm>sha1</hash-algorithm>
			<dhgroup>2</dhgroup>
			<lifetime>3600</lifetime>
			<pre-shared-key>hdhdhdjdjdhdj</pre-shared-key>
			 <private-key><certref>4cdc19617089e</certref>
			 <caref><authentication_method>pre_shared_key</authentication_method>
			 <proposal_check><nat_traversal>off</nat_traversal>
			<dpd_delay>10</dpd_delay>
			<dpd_maxfail>5</dpd_maxfail></proposal_check></caref></private-key></phase1> 
		 <phase2><ikeid>1</ikeid>
			<mode>tunnel</mode>
			 <localid><type>network</type>

<address>10.19.0.0</address>

				<netbits>22</netbits></localid> 
			 <remoteid><type>network</type>

<address>10.19.8.0</address>

				<netbits>22</netbits></remoteid> 
			<protocol>esp</protocol>
			 <encryption-algorithm-option><name>aes</name>
				<keylen>128</keylen></encryption-algorithm-option> 
			<hash-algorithm-option>hmac_sha1</hash-algorithm-option>
			<pfsgroup>2</pfsgroup>
			<lifetime>3600</lifetime>
			<pinghost>10.19.9.1</pinghost></phase2>

ggzengel

What has changed that it is necessary?

I answer myself.
If have seen last commit from ermal:
https://github.com/bsdperimeter/pfsense/commit/94395d8672f48b96528684cb9f98f082c8c52875

mdima

mmmhhh… something changed in the release, since the configuration has not been altered pre and post the update.

Do we have to apply the change in "net.enc.in.ipsec_filter_mask" or someone will revert the change in pfSense that caused the problem?

Thanks,
Michele

ggzengel

Do we have to apply the change in "net.enc.in.ipsec_filter_mask" or someone will revert the change in pfSense that caused the problem?

Ermal has reverted the change. Until next snapshot you have to apply sysctl manual.
Don't forget to delete net.enc.in.ipsec_filter_mask if you have applied the next snapshot because this has not to be set manual under normal circumstances.

rkelleyrtp

Very timely thread. I just upgraded from 2.0.2 to 2.1 beta and all my RDP sessions across the IPSec tunnels kept timing out. After adding the "net.enc.in.ipsec_filter_mask" tunable with value 0x0002 worked perfectly!

mdima

With the latest release (2.1-BETA1 (i386) \ Wed Feb 6 19:40:53 EST 2013) seems working fine…

For the ones who added the "net.enc.in.ipsec_filter_mask", seems they should remove it! ;)

Thanks to Ermal for fixing it!

Michele

eri--

Yeah, sorry for the trouble and thank you for the reports.
The fix is intended for some ipsec configs but i will check how to make it less problematic.