NPPPD Server behind a firewall

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

NPPPD Server behind a firewall

Damian McGuckin

I have a L2TP NPPPD server machine with IP $L2TP sitting behind an OpenBSD
firewall, say FIRET. 'T' for temporary because it will move. $L2TP is an
externally routable IP. $Ext, the external interface of FIRET, allows
traffic into $L2TP. A snippet of pf.conf is

----begin snippet-0
ipsecIN = "{ iskmpd, ipsec-nat-t, l2tp }"

pass in quick on $Ext inet proto udp from any to $L2TP port $ipsecIN keep state
pass in quick on $Ext inet proto esp from any to $L2TP
pass in quick on $Ext inet proto ah from any to $L2TP
----end snippet-0

It all went wonderfully. It worked. I have done it before.

Because I had a working L2TP server setup on $L2TP, I was not going to
go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf

     ike passive esp transport \
         proto udp from egress to any port 1701 \
         main auth "hmac-sha1" enc "3des" group modp1024 \
         quick auth "hmac-sha1" enc "3des" group modp1024 \
         psk "MYSECRET"

Now I want to move the machine to a new site behind a new OpenBSD firewall,
say FIRE. The difference is that now, $L2TP will have an unroutable address,
say 10.200.100.200, or $L2TPI, as the IP on its external interface.  It will
obviously have an external address, $L2TPX, but that will be exposed through
FIRE, the external firewall. I want to binat from L2TPX->L2TPI.

So on FIRE, where we will call the external interface, $Ext, again. I
first binat things on FIRE.

  match on $Ext from $L2TPI to any binat to $L2TPX

Because BINAT'ing is done before 'pass' rules are processed, the rules must
refer to the external interface.  Just to be sure, I will ensure that I can
SSH to $L2TPI, on FIRE I have a pf.conf with

  pass in quick on $Ext inet proto tcp from any to $L2TPI port ssh\
  flags S/SA modulate state

Yes, that works. I can SSH to $L2TPX and get all the way through FIRE and
get in through the interface $L2TPI of the NPPPD server.

OK, now I need to let the other protocols through. I think I want all
traffic, once it gets onto $Ext, to be allowed through to the internal
network on which $L2TPI sits with its IP 10.200.100.200.

----begin snippet-1

ipsecIN = "{ iskmpd, ipsec-nat-t, l2tp }"

pass in quick on $Ext inet proto udp from any to $L2TPI port $ipsecIN keep state
pass in quick on $Ext inet proto esp from any to $L2TPI
pass in quick on $Ext inet proto ah from any to $L2TPI

----end snippet-1

I can see traffic destined to 10.200.100.200 coming in through the external
interface of FIRE and going out to 10.200.100.200 and then, from within this
machine, i.e. the NPPPD Server, I see traffic coming in, admittedly on port
ipsec-nat-t, i.e. 4500. But it fails.

Any suggestions on what I have done wrong or what I need to do right.

Thanks - Damian

Reply | Threaded
Open this post in threaded view
|

Re: NPPPD Server behind a firewall

Stefan Sperling-5
On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote:
> Because I had a working L2TP server setup on $L2TP, I was not going to
> go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf
>
>     ike passive esp transport \
>         proto udp from egress to any port 1701 \
>         main auth "hmac-sha1" enc "3des" group modp1024 \
>         quick auth "hmac-sha1" enc "3des" group modp1024 \
>         psk "MYSECRET"

As an aside, you should avoid use of 3des because it is effecively plaintext.
There are ways to make even Windows clients use actual crypto with IPsec if
needed, though last I checked it could not be done from the GUI but required
powershell commands. (I don't have a URL handy, sorry, but this information
wasn't very hard to find when I needed it.)
 
> Now I want to move the machine to a new site behind a new OpenBSD firewall,
> say FIRE. The difference is that now, $L2TP will have an unroutable address,
> say 10.200.100.200, or $L2TPI, as the IP on its external interface.  It will
> obviously have an external address, $L2TPX, but that will be exposed through
> FIRE, the external firewall. I want to binat from L2TPX->L2TPI.

> Any suggestions on what I have done wrong or what I need to do right.

You could try to pin-point the problem a bit more, starting with diagnostics
at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc.
I suspect getting IPsec SAs going with both peers behind NAT is tricky.
I believe it should be possile in theory but I cannot confirm whether our
implementation can do this easily. It will certainly involve UDP traffic
since AH/ESP cannot pass through NAT.

If your IPsec SAs already work for other traffic, but npppd won't work,
that would imply that npppd has a limitation related to NAT; perhaps it
encodes the end-point IPs it is seeing in the L2TP protocol, which would
not match the actual layer 3 addresses used by IPsec?

Reply | Threaded
Open this post in threaded view
|

Re: NPPPD Server behind a firewall

Damian McGuckin
In reply to this post by Damian McGuckin

I changed /etc/ipsec.conf to have 'ike' reflect the external IP

ike passive esp transport \
  proto udp from $L2TPX to any port 1701 \
  main auth "hmac-sha1" enc "aes" group modp2048 \
  quick auth "hmac-sha1" enc "aes" group modp2048 \
  psk "MYSECRET"

and restarted isakmpd and reloaded ipsec.conf.

On the inside of the NPPPD server, the only errors I get are

isakmpd[46608]: attribute_unacceptable: GROUP_DESCRIPTION: got ECP_384, expected MODP_2048
isakmpd[46608]: attribute_unacceptable: GROUP_DESCRIPTION: got ECP_256, expected MODP_2048

and I believe it should negotiate the groups. It should also negotiate "3des"
and my earlier "modp1024" but I wanted to minimize lines of errors.

While this is happening....

ipsecctl -s flow (shows)

flow esp in proto udp from REMOTE-FW port l2tp to $L2TPI port l2tp peer
     REMOTE-FW srcid $L2TPI/32 dstid 192.168.0.146/32 type use
flow esp out proto udp from $L2TPI port l2tp to REMOTE-FW port l2tp peer
     REMOTE-FW srcid $L2TPI/32 dstid 192.168.0.146/32 type require

Note that there are only 2 lines above. I

Which reflects the network

  [laptop-192.168.0.146]<->REMOTE-FW --internet-- FIRE<->SERVER-IP=$L2TPI)

and the firewall FIRE nats $L2TPX->$L2TPI

But, the VPN is never established, eventually

ipsecctl -s flow (shows)

<nothing>

Still at a loss.  Any suggestions?

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Reply | Threaded
Open this post in threaded view
|

Re: NPPPD Server behind a firewall

Damian McGuckin
In reply to this post by Stefan Sperling-5
On Mon, 14 Oct 2019, Stefan Sperling wrote:

> On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote:
>> Because I had a working L2TP server setup on $L2TP, I was not going to
>> go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf
>>
>>     ike passive esp transport \
>>         proto udp from egress to any port 1701 \
>>         main auth "hmac-sha1" enc "3des" group modp1024 \
>>         quick auth "hmac-sha1" enc "3des" group modp1024 \
>>         psk "MYSECRET"
>
> As an aside, you should avoid use of 3des because it is effecively
> plaintext.

I take your point about 3des but I was starting from a known configuration
which works (albiet with the external interface hacing a Public IP)

> There are ways to make even Windows clients use actual crypto with IPsec if
> needed, though last I checked it could not be done from the GUI but required
> powershell commands. (I don't have a URL handy, sorry, but this information
> wasn't very hard to find when I needed it.)

Thanks. I will investigate. This has to work with iPads as well. Yuk!

> You could try to pin-point the problem a bit more, starting with diagnostics
> at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc.

OK.

> I suspect getting IPsec SAs going with both peers behind NAT is tricky.

I agree.

See my subsequent post where I replaced 'egress' above with the external
IP (of the subsequently NAT'd npppd server). Closer. But not quite there.

Thanks - Damian

Reply | Threaded
Open this post in threaded view
|

Re: NPPPD Server behind a firewall

Stuart Henderson
>> There are ways to make even Windows clients use actual crypto with IPsec if
>> needed, though last I checked it could not be done from the GUI but required
>> powershell commands. (I don't have a URL handy, sorry, but this information
>> wasn't very hard to find when I needed it.)
>
> Thanks. I will investigate. This has to work with iPads as well. Yuk!

I would srongly recommend switching to IKEv2 if you can, it is far easier
to come up with a config that still gives decent crypto with mixed client
platforms. (Internal client on Apple OS and non-ancient Windows -
strongswan on Android/Linux).

>> I suspect getting IPsec SAs going with both peers behind NAT is tricky.
>
> I agree.

The IPsec side should be ok as long as everything supports nat-t (not unusual).


Reply | Threaded
Open this post in threaded view
|

Re: NPPPD Server behind a firewall

Damian McGuckin
On Wed, 16 Oct 2019, Stuart Henderson wrote:

> I would srongly recommend switching to IKEv2 if you can, it is far
> easier to come up with a config that still gives decent crypto with
> mixed client platforms. (Internal client on Apple OS and non-ancient
> Windows - strongswan on Android/Linux).

I do not disagree.

I just need to move an existing NPPPD to behind a firewall in the short
term that serves several iPads and Windows PCs. Once I have the move done,
I want to move expand to IKEv2. I was also under the impression that IKEv2
was faster.

> The IPsec side should be ok as long as everything supports nat-t (not
> unusual).

I am still stuck and will try some new things on Monday.

Regards - Damian