What is the difference between the following? And what is the correct usage?
chain=input action=accept protocol=ipsec-esp in-interface=ether1-Internet
chain=input action=accept protocol=udp in-interface=ether1-Internet dst-port=500,4500
chain=input action=accept ipsec-policy=in,ipsec
First will accept encrypted packets. Last will accept decrypted packets. Middle one is for negotiation between the two ends, and also in some cases for encrypted packets (when there’s NAT in the way, ESP packets could have trouble passing, so they are wrapped in UDP).
An analogy could be postman delivering mail. First rule accepts the unopened envelope. Last rule accepts what is in envelope. Middle rule allows to talk with postman about delivering envelope, setting rules how the delivery will work, etc. Only the special case with NAT is difficult to explain this way.
That…made quite a bit of sense. But with that said:
For “full” implementation, do I need to have all three specified at a filter and NAT level?
You need first two to establish tunnel. Last one depends on whether you need to have access from tunnel to this router. If not, you don’t need this rule. But you may need it in chain=forward if there should be access from tunnel to LAN. Also depending on your exact needs, you may need exemption from main srcnat/masquerade for tunnelled traffic. If you want better answer, you should provide more details about what exactly are you doing and what are your requirements.
What I’m doing - part experimenting and part really trying to understand this. In particular, the first thing I wanted working was OSPF. The second was being able to reliably gain access to hosts on either side of the tunnel. Part of that is implementing layer 2 connectivity in some fashion - not sure how yet.
My present config, I have
chain=input action=accept protocol=udp in-interface=ether1-Internet dst-port=500,4500
running on my main router. While I do have
chain=input action=accept protocol=ipsec-esp in-interface=ether1-Internet
defined prior to the 500,4500 rule - I never see any packets hit it.
My first src-nat rule is
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
. I have experimented with
chain=srcnat action=src-nat to-addresses=10.21.3.1 out-interface-list=WAN log=no log-prefix="" ipsec-policy=out,ipsec
but regardless of rule order it only gets an occasional packet - typically when first connecting to a remote.
I finally understood one of the basic principles - IPSEC is not multicast. And “simple” OSPF requires multicast. But a fairly simple workaround - define NBMA neighbors & interfaces at each end and things look fine. So…I think that resolves my OSPF challenges. Next:
At one time I know I had layer 2 tunnels working - which is how OSPF used to work. It was using some combination of EoIP and/or VPLS - but enabling the previously configured interfaces doesn’t appear to do much. So my next question - which perhaps belongs as a new thread - is where to start setting up a layer 2 tunnel.
Any further comments on firewall filter/NAT please reply here - otherwise I’m starting a new thread for the layer 2 tunnel.