<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Need some guidance on IPsec firewall rules]]></title><description><![CDATA[<p dir="auto">Hi,</p>
<p dir="auto">After several days of trail and error, I have now got an IPsec tunnel up, connecting to a Cisco firewall at a supplier.  There are some issues if the Cisco end brings up the tunnel, but if I initiate the link, it seems rock solid.</p>
<p dir="auto">My query is on the adding of the necessary firewall rules to lock down the traffic allowed onto my network from the VPN tunnel.</p>
<p dir="auto">Currently, I have a couple of rules on my WAN interface that let through UDP/500 and UDP/4500 packets so that the remote end can initiate the link if necessary.</p>
<pre><code>
IPv4 UDP 	* 	* 	WAN address 	4500 (IPsec NAT-T) 	* 	none               IPsec VPN  
IPv4 UDP 	* 	* 	WAN address 	500 (ISAKMP) 	        * 	none               IPsec VPN

</code></pre>
<p dir="auto">I also have a completely open rule on the IPsec tab to allow all traffic over the IPsec link.</p>
<pre><code>
IPv4 * 	* 	* 	* 	* 	* 	none 	  	Supplier IPsec vpn  

</code></pre>
<p dir="auto">What I would really like to do is lock down the traffic that can get onto my local network from the supplier network over the IPsec link.  I can't work out whether the rule should go on the LAN tab (I think this is favourite based on my readings of previous posts), or on the WAN tab, or whether I should amend the rule on the IPsec tab to be more closely controlled.</p>
<p dir="auto">My network: 192.168.111.0/24<br />
Supplier network:  172.16.5.0/24</p>
<p dir="auto">I only want the supplier network to be able to talk with a single host on my local network, 192.168.111.4.</p>
<p dir="auto">I'm thinking I need something like the following rule, but I don't know exactly where to put it, assuming it is correct in what I am trying to achieve.</p>
<pre><code>
(Rule is set up as BLOCK)
x   IPv4 * 	172.16.5.0/24 	* 	! 192.168.111.4 	* 	* 	none 	  	Only allow remote network to access single local host 

</code></pre>
<p dir="auto">I read this rule as follows :-</p>
<p dir="auto">Block any packet from the supplier network (by definition over the IPsec VPN) that isn't destined for the desired single host on my network.</p>
<p dir="auto">Is this rule correct ?</p>
<p dir="auto">Which firewall rules tab should I put it on ?  LAN ? WAN ? IPsec ?</p>
<p dir="auto">Thanks.</p>
]]></description><link>https://forum.netgate.com/topic/58491/need-some-guidance-on-ipsec-firewall-rules</link><generator>RSS for Node</generator><lastBuildDate>Sun, 08 Mar 2026 17:08:46 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/58491.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 18 Jul 2013 14:21:27 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Need some guidance on IPsec firewall rules on Thu, 18 Jul 2013 18:31:28 GMT]]></title><description><![CDATA[<p dir="auto">Hello,</p>
<p dir="auto">The first thing to remember is that the firewall is a default "block all", therefore you only need to allow access from their hosts to your one.</p>
<blockquote>
<p dir="auto">(Rule is set up as BLOCK)<br />
x  IPv4 * 172.16.5.0/24 * ! 192.168.111.4 * * none   Only allow remote network to access single local host<br />
…<br />
Block any packet from the supplier network (by definition over the IPsec VPN) that isn't destined for the desired single host on my network</p>
</blockquote>
<p dir="auto">Second is to remember that rules apply on INBOUND connections, thus you want a rule like this on your IPSEC interface.</p>
<p dir="auto">Thus, the psuedo-code would read:</p>
<p dir="auto">"allow all traffic from 172.16.5.0/24 to 192.168.111.4"</p>
<p dir="auto">–jason</p>
]]></description><link>https://forum.netgate.com/post/406600</link><guid isPermaLink="true">https://forum.netgate.com/post/406600</guid><dc:creator><![CDATA[jason0]]></dc:creator><pubDate>Thu, 18 Jul 2013 18:31:28 GMT</pubDate></item></channel></rss>