Re: l2tp / ipsec follow up

2014-07-30 Thread Gordon Turner 

On 2014-07-28 08:43, John wrote:

On Sun, Jul 27, 2014 at 02:07:34PM -0400, Gordon Turner wrote:

On 2014-07-27 10:16, John wrote:
On Sat, Jul 26, 2014 at 05:34:56PM -0400, Gordon Turner wrote:
On 2014-07-23 20:30, Gordon Turner wrote:

Does your gateway at 192.168.2.1 know how to reach 10.0.0.0/24?  Does it
have a route telling it to use 192.168.2.140 to reach 10.0.0.0/24?


I don't have any other routes setup, I guess I am struggling with 
where

should I add them?


If I understand your network topology correctly, you need to add a 
route

to 10.0.0.0/24 on the gateway device 192.168.2.1 otherwise return
traffic from 192.168.2.0/24 to 10.0.0.0/24 is probably taking some 
other

path or getting dropped.

So on the gateway which is 192.168.2.1:
  /sbin/route add 10.0.0.0/24 192.168.2.140


That, eventually, did the the trick.

That was one of the first things I tried, but the route (for some 
reason) wasn't used immediately.  I rebooted the OpenVPN and restarted 
the gateway router and then things were working!  Yay!


I will eventually move the VPN end point to the new gateway / router, 
but for now it is nice to have them decoupled.



I did have 2 more questions that someone might be able to help with:


Does `framed-ip-address` in `npppd-users` assign an ip address to the 
user when authenticated?  That was my expectation, but when I provide an 
ip from the `pool-address` range, the value is not used.  Another value 
from the pool is used instead.

```
jtest:\
:password=SEEKRIT:\
:framed-ip-address=10.0.0.2:
```


With regards to adding extra rules to pf.conf for the VPN traffic, if I 
am relying on l2tp and ipsec for authentication, and I trust those 
connecting completely (ie me) is there any risk NOT not adding 
additional filtering rules?


To put a different way, I want to have VPN clients treated as if they 
were on the private network natively.  I am only forwarding TCP 500, 
4500 to the VPN endpoint which is listening for them.

```
set skip on pppx0
pass in quick on egress proto udp from any to any port {500, 4500} keep 
state

pass on enc0 from any to any keep state (if-bound)
```

Thanks!
Gord.

Re: l2tp / ipsec follow up

2014-07-28 Thread mxb 
I suggested to re-configure your cable modem as a bridge,
so your OpenBSD-box gets public IP and not private (as you have it now).

On old days then I had a cable modem, I done exactly like this.

This WILL make your life easier. Trust me.
As you don’t really have any control of OS(Linux) inside your cable modem.
Nor services (ex. dhcpd) running inside.

And then you get connection problems, you’ll look for a problem and will end
up in
resetting/rebooting several devices(modem, openbsd-box).

//mxb

On 27 jul 2014, at 22:58, Gordon Turner tur...@ftn.net wrote:

 The OpenBSD ip (192.168.2.232) is statically assigned by the dhcp server.

Re: l2tp / ipsec follow up

2014-07-27 Thread Gordon Turner 

On 2014-07-27 08:06, Stefan Sieg wrote:

On 26.07.2014 17:34, Gordon Turner wrote:

But any attempt to reach the 192.168.2.0/24 network fails.


did you set the route on your clients accordingly, so that they know 
how to reach that network?


After connecting the VPN, I tried adding different routes on the client:

/sbin/route add 192.168.2.0/24 10.0.0.186

and when that didn't work I rebooted, connected the VPN and tried:

/sbin/route add 192.168.2.0/24 10.0.0.1

I admit that I have never needed to add routes before so I am starting 
from scratch here.


I also check the 'Send all traffic over VPN connection', but if I 
understand things correctly, the traffic gets to 10.0.0.1 and has no 
where to go.



pass in quick on egress proto udp from any to any port {500, 4500, 
1701} keep state


You don't need to forward l2tp on your router, it is encapsulated in 
ipsec.



pass quick proto { esp, ah } from any to any


As long as NAT is involved you dont need ESP in your pf.conf, it is 
encapsulated in UDP. You dont need AH.


Thanks for that, I have updated my pf.conf to:
```
set skip on pppx0
pass in quick on egress proto udp from any to any port {500, 4500} keep 
state

pass on enc0 from any to any keep state (if-bound)
```



Looking for some help with finishing this last piece, I am no longer
sure if it a pf issue, it might be a default route problem.


tcpdump and pfs log option are very usefull to see whats going on.



$ sudo tcpdump -ni pppx0
tcpdump: listening on pppx0, link-type LOOP
12:41:04.014922 10.0.0.75.54342  8.8.8.8.53: 39507+ SRV? 
_ldap._tcp.mythum.lan. (39)
12:41:05.783767 10.0.0.75.55149  8.8.8.8.53: 37421+ A? 
p01-streams.icloud.com. (40)
12:41:06.982890 10.0.0.75.54342  8.8.8.8.53: 39507+ SRV? 
_ldap._tcp.mythum.lan. (39)
12:41:08.454573 10.0.0.75.53042  8.8.8.8.53: 57936+ A? 
p21-calendars.icloud.com. (42)
12:41:09.464456 10.0.0.75.53042  8.8.8.8.53: 57936+ A? 
p21-calendars.icloud.com. (42)
12:41:12.493838 10.0.0.75.53042  8.8.8.8.53: 57936+ A? 
p21-calendars.icloud.com. (42)
12:41:13.513972 10.0.0.75.53042  8.8.8.8.53: 57936+ A? 
p21-calendars.icloud.com. (42)
12:41:14.444208 10.0.0.75.51500  8.8.8.8.53: 52450+ SRV? 
_kerberos._udp.MYTHUM.LAN. (43)
12:41:14.892284 10.0.0.75.55149  8.8.8.8.53: 37421+ A? 
p01-streams.icloud.com. (40)
12:41:15.474692 10.0.0.75.51500  8.8.8.8.53: 52450+ SRV? 
_kerberos._udp.MYTHUM.LAN. (43)
12:41:16.103557 10.0.0.75.54342  8.8.8.8.53: 39507+ SRV? 
_ldap._tcp.mythum.lan. (39)

tcpdump: WARNING: compensating for unaligned libpcap packets
12:41:16.574507 10.0.0.75.53042  8.8.8.8.53: 57936+ A? 
p21-calendars.icloud.com. (42)
12:41:18.493783 10.0.0.75.51500  8.8.8.8.53: 52450+ SRV? 
_kerberos._udp.MYTHUM.LAN. (43)
12:41:19.365219 10.0.0.75.49404  8.8.8.8.53: 56240+ A? 
12-courier.push.apple.com. (43)
12:41:19.574170 10.0.0.75.51500  8.8.8.8.53: 52450+ SRV? 
_kerberos._udp.MYTHUM.LAN. (43)
12:41:20.372149 10.0.0.75.49404  8.8.8.8.53: 56240+ A? 
12-courier.push.apple.com. (43)
12:41:22.664149 10.0.0.75.51500  8.8.8.8.53: 52450+ SRV? 
_kerberos._udp.MYTHUM.LAN. (43)
12:41:23.451963 10.0.0.75.49404  8.8.8.8.53: 56240+ A? 
12-courier.push.apple.com. (43)

12:41:24.453283 10.0.0.75  192.168.2.225: icmp: echo request
12:41:24.461780 10.0.0.75.49404  8.8.8.8.53: 56240+ A? 
12-courier.push.apple.com. (43)
12:41:24.461833 10.0.0.75.64324  8.8.8.8.53: 32547+ SRV? 
_kerberos._tcp.MYTHUM.LAN. (43)

12:41:25.453901 10.0.0.75  192.168.2.225: icmp: echo request
12:41:25.542776 10.0.0.75.64324  8.8.8.8.53: 32547+ SRV? 
_kerberos._tcp.MYTHUM.LAN. (43)
12:41:25.592847 10.0.0.75.53042  8.8.8.8.53: 57936+ A? 
p21-calendars.icloud.com. (42)

12:41:26.453321 10.0.0.75  192.168.2.225: icmp: echo request
12:41:27.453650 10.0.0.75  192.168.2.225: icmp: echo request
12:41:27.532806 10.0.0.75.49404  8.8.8.8.53: 56240+ A? 
12-courier.push.apple.com. (43)

12:41:28.463647 10.0.0.75  192.168.2.225: icmp: echo request
12:41:28.663012 10.0.0.75.64324  8.8.8.8.53: 32547+ SRV? 
_kerberos._tcp.MYTHUM.LAN. (43)
12:41:29.723006 10.0.0.75.64324  8.8.8.8.53: 32547+ SRV? 
_kerberos._tcp.MYTHUM.LAN. (43)




$ sudo tcpdump -ni enc0
tcpdump: listening on enc0, link-type ENC
12:42:13.722514 (authentic,confidential): SPI 0xc4ae1209: 
24.114.54.8.65247  192.168.2.232.1701: l2tp:[L](3/2779)[hdlc|][|l2tp]
12:42:14.092443 (authentic,confidential): SPI 0xc4ae1209: 
24.114.54.8.65247  192.168.2.232.1701: l2tp:[L](3/2779)[hdlc|][|l2tp]
12:42:14.742843 (authentic,confidential): SPI 0xc4ae1209: 
24.114.54.8.65247  192.168.2.232.1701: l2tp:[L](3/2779)[hdlc|][|l2tp]
12:42:15.163667 (authentic,confidential): SPI 0xc4ae1209: 
24.114.54.8.65247  192.168.2.232.1701: l2tp:[L](3/2779)[hdlc|][|l2tp]
12:42:17.752480 (authentic,confidential): SPI 0xc4ae1209: 
24.114.54.8.65247  192.168.2.232.1701: l2tp:[L](3/2779)[hdlc|][|l2tp]
12:42:18.212499 (authentic,confidential): SPI 0xc4ae1209: 
24.114.54.8.65247  192.168.2.232.1701: l2tp:[L](3/2779)[hdlc|][|l2tp]
12:42:18.321068 (authentic,confidential): SPI 0xc4ae1209:

Re: l2tp / ipsec follow up

2014-07-27 Thread Gordon Turner 

On 2014-07-27 18:04, Stefan Sieg wrote:

On 27.07.2014 13:46, Gordon Turner wrote:

On 2014-07-27 08:06, Stefan Sieg wrote:
On 26.07.2014 17:34, Gordon Turner wrote:


and you need a route to 10.0.0.0/24 for the hosts in your
192.168.2.0/24 network.
Without that route your hosts in your LAN have no idea how to reach
10.0.0.0/24. This is needed because your VPN is not terminated on your
default gateway.
If the address of your OpenBSD box is assigned by dhcp, then you should 
change

that to static and use this as the gateway to 10.0.0.0/24.



The OpenBSD ip (192.168.2.232) is statically assigned by the dhcp 
server.


I added a static route to my router / firewall:
Destination: 10.0.0.0
Gateway: 192.168.2.232
Subnet Mask: 255.255.255.0

But testing with an iOS device that doesn't seem to be enough.

Do I have to add routing on the OpenBSD box?



If this is your whole config then actually everything is allowed,
you might want to change that ... the pf faq is really good.


Yeah, definitely, once I get the routing sorted.

Gord

Re: l2tp / ipsec follow up

2014-07-26 Thread Gordon Turner 

On 2014-07-23 20:30, Gordon Turner wrote:

Hey all,

Based on the feedback from Daniel and others, I have successfully
connected to my OpenBSD instance running behind my router / firewall
from an iOS and OSX client on the Internet.  (Updated instructions
below.)

The one issue that I have is that requests to the local private
network are being lost.  My Packet Filter kung fu is a little rusty,
the only entries in the pf.conf at the moment are:



Looking for some help with finishing this last piece, I am no longer 
sure if it a pf issue, it might be a default route problem.


From a client connecting successfully, I can ping the 10.0.0.1 end point 
on the OpenBSD box.


But any attempt to reach the 192.168.2.0/24 network fails.

The routing table looks like:

```
$ netstat -rn -f inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio 
Iface
default192.168.2.1UGS3   99 - 8 
vio0
10.0.0.89  10.0.0.1   UH 00 - 4 
pppx0
127/8  127.0.0.1  UGRS   00 33144 8 
lo0
127.0.0.1  127.0.0.1  UH 10 33144 4 
lo0
192.168.2/24   link#1 UC 20 - 4 
vio0
192.168.2.100:25:9c:28:2d:4b  UHLc   1  159 - 4 
vio0
192.168.2.140  7c:d1:c3:e9:68:e9  UHLc   1  228 - 4 
vio0
224/4  127.0.0.1  URS00 33144 8 
lo0

```

What route should I be adding, if any, to successfully reach the 
192.168.2.0/24 network (and the the Internet?) from the VPN client?


Thanks!
Gord.






Current configuration details, slightly updated
--
VPN OpenBSD L2TP-IPSEC
==


Description
---
- Using OpenBSD 5.5 as an VPN end point for iOS 7.0 and OSX 10.9 
clients.

  - Support for iOS, preferably native VPN client
  - Support for OSX, preferably native VPN client

- VPN endpoint running on an internal server.
- Forwarding appropriate ports from a router.

- Use npppd, IPsec and Packet Filter (pf).


NAT and Port Forwarding
---
- The VPN end point is behind a NATed firewall and the following ports 
are forwarded:

UDP 500  - Internet Key Exchange (IKE)
UDP 1701 - L2TP traffic
UDP 4500 - IPSec Network Address Translation (NAT-T)


npppd Setup
---
- npppd is a Point-to-Point Protocol (PPP) and tunneling daemon capable 
of L2TP, PPTP, and PPPoE.


- Reference:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/npppd.8
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/npppd.conf.5

- NOTE:
Private network is 192.168.2.0/24 (192.168.2.0-192.168.2.254)
DNS server / router / fire wall is 192.168.2.1
VPN network is 10.0.0.0/24 (10.0.0.2-10.0.0.254)
VPN network gateway to private network is 10.0.0.1
Using local file authentication

- Example npppd.conf file, `/etc/npppd/npppd.conf`:
```
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}

tunnel L2TP_ipv4 protocol l2tp {
listen on 0.0.0.0
}

ipcp IPCP {
pool-address 10.0.0.2-10.0.0.254
#dns-servers 8.8.8.8
dns-servers 192.168.2.1
}

interface pppx0 address 10.0.0.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
```
- NOTE:
The `pool-address` values should be a block of addresses in a 
different subnet of the internal network.
The `dns-servers 8.8.8.8` is Google's public dns, local local DNS 
servers should be used if available.



- Example npppd-users file, `/etc/npppd/npppd-users`:
```
jtest: \
:password=SEEKRIT: \
:framed-ip-address=10.0.0.100:
```
- NOTE:
Replace `SEEKRIT` with your password.
The `framed-ip-address` value, if used, should be in the 
`pool-address` block from `/etc/npppd/npppd.conf`.



IPsec Setup
---
- IPsec is a pair of protocols, Encapsulating Security Payload (ESP) and 
Authentication Header (AH), which provide security services for IP 
datagrams.


- Reference:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ipsec.4


- Example ipsec.conf file, `/etc/ipsec.conf`:
```
public_ip = XXX.XXX.XXX.XXX

ike passive esp transport \
  proto udp from $public_ip to any port 1701 \
  main auth hmac-sha1 enc aes group modp1024 \
  quick auth hmac-sha1 enc aes \
  psk SEEKRIT
```
- NOTE:
Replace XXX.XXX.XXX.XXX with external public ip on the Internet.
Replace SEEKRIT with your password.


Packet Filter Setup
---
- Packet Filter is OpenBSD's system for filtering TCP/IP traffic and 
doing Network Address Translation.


- Reference:
http://www.openbsd.org/faq/pf/
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/pf.4


- Example pf.conf file, `/etc/pf.conf`:
```
set skip on pppx0
pass quick proto { esp, ah } from any to any
pass in quick on egress proto udp from any to any port {500, 4500, 1701} 
keep state

pass on enc0 from any to any

l2tp / ipsec follow up

2014-07-23 Thread Gordon Turner 

Hey all,

Based on the feedback from Daniel and others, I have successfully 
connected to my OpenBSD instance running behind my router / firewall 
from an iOS and OSX client on the Internet.  (Updated instructions 
below.)


The one issue that I have is that requests to the local private network 
are being lost.  My Packet Filter kung fu is a little rusty, the only 
entries in the pf.conf at the moment are:


```
pass quick proto { esp, ah } from any to any
pass in quick on egress proto udp from any to any port {500, 4500, 1701} 
keep state

pass on enc0 from any to any keep state (if-bound)
```

I am not sure what device to 'passs in' on at the end of the l2tp / 
ipsec to enable nat'ing and accessing internal network resources.


(There was feedback that `pool-address 10.0.0.1-10.0.0.100` and 
`:framed-ip-address=10.0.0.10:` had to be a different network then the 
private internal network.)


The router / firewall has a working dhcp server running.

```
ifconfig -a
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33144
priority: 0
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
vio0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 52:54:00:9b:3b:bc
priority: 0
groups: egress
media: Ethernet autoselect
status: active
inet6 fe80::5054:ff:fe9b:3bbc%vio0 prefixlen 64 scopeid 0x1
inet 192.168.2.232 netmask 0xff00 broadcast 192.168.2.255
enc0: flags=0
priority: 0
groups: enc
status: active
pflog0: flags=141UP,RUNNING,PROMISC mtu 33144
priority: 0
groups: pflog
pppx0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1360
description: gturner
priority: 0
groups: pppx
inet 192.168.2.1 -- 10.0.0.97 netmask 0x
```

Again, any pointers appreciated.

Gord.





VPN OpenBSD L2TP-IPSEC (mostly working-ish)
===

Requirements
---
- Using OpenBSD 5.5 as an VPN end point for iOS 7.0 and OSX 10.9 
clients.

  - Support for iOS, preferably native VPN client
  - Support for OSX, preferably native VPN client

- VPN endpoint running on an internal server.
- Forwarding appropriate ports from a router.


Description
---
- Use npppd, IPsec and Packet Filter (pf).
  - Configuration files `/etc/npppd/npppd.conf`, 
`/etc/npppd/npppd-users`, `/etc/ipsec.conf` and `/etc/pf.conf`.


- Reference:
http://www.slideshare.net/GiovanniBechis/npppd-easy-vpn-with-openbsd
http://undeadly.org/cgi?action=articlesid=20120427125048
http://comments.gmane.org/gmane.os.openbsd.misc/209636
http://stackoverflow.com/questions/14967962/openbsd-ipsec-vpn-not-routing-traffic
http://www.packetmischief.ca/openbsd-ipsec-tunnel-guide/

- Claims to have it working, on internet facing machine:
https://www.mail-archive.com/misc@openbsd.org/msg125930.html

- Reference for supported protocols and authentication methods fo iOS:
http://support.apple.com/kb/HT1288


npppd Setup
---
- npppd is a Point-to-Point Protocol (PPP) and tunneling daemon capable 
of L2TP, PPTP, and PPPoE.


- Reference: 
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/npppd.8?manpath=OpenBSD-currentsec=8query=npppd

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/npppd.conf.5?manpath=OpenBSD-currentsec=5query=npppd.conf

- NOTE: Private network is 192.168.2.x.
- NOTE: Using local file authentication.

- Example npppd.conf file, `/etc/npppd/npppd.conf`:
```
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}

tunnel L2TP_ipv4 protocol l2tp {
listen on 0.0.0.0
}

ipcp IPCP {
pool-address 10.0.0.1-10.0.0.100
dns-servers 8.8.8.8
}

interface pppx0 address 192.168.2.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
```
- NOTE: `pool-address` valus should be a block of addresses in the same 
subnet of the internal network.
- NOTE: `dns-servers 8.8.8.8` is Google's public dns, local local DNS 
servers should be used if available.



- Example npppd-users file, `/etc/npppd/npppd-users`:
```
jtest: \
:password=SEEKRIT:\
:framed-ip-address=10.0.0.10:
```
- NOTE: Replace `SEEKRIT` with your password.
- NOTE: The `framed-ip-address` value should be in the `pool-address` 
block from `/etc/npppd/npppd.conf`.



IPsec Setup
---
- IPsec is a pair of protocols, Encapsulating Security Payload (ESP) and 
Authentication Header (AH), which provide security services for IP 
datagrams.


- Reference:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ipsec.4?manpath=OpenBSD-currentquery=ipsec

- NOTE: Private network is 192.168.2.x.

- Example ipsec.conf file, `/etc/ipsec.conf`:
```
public_ip = 192.168.2.2

ike passive esp transport \
  proto udp from $public_ip to any port 1701 \
  main auth hmac-sha1 enc aes group modp1024 \
  quick auth hmac-sha1 enc aes \
  psk SEEKRIT
```
- NOTE: