Openvpn problem with 2rc1

  • Hi everyone,

    this is my topology:

    LAN: Multiple subnets of with OSPF routing protocol
    Default gateway: juniper firewall connected by point-to-point OSPF link: (Juniper is (WAN Juniper interface has public static IP, let's say
    PFSense role and position:
    LAN Interface: connected by subnet ( PFSense)
    WAN: connected with static public IP (different from juniper, lets say
    PFSense Static Routes: gw (for LAN connections) gw (that is the remote ISP router)

    PFsense should work has OVPN concentrator.
    I managed to crete SSL/TLS+Auth connection from a remote client.
    PFsense correctly assigns a /30 subnet to ovpn connection taken from address pool
    PFsense correctly pushes route to remote client.
    Connection is correctly established!!
    However, client can't go anywhere in

    I've tried the wizard, it configured firewall rules. The problem is routing or firewalling, I'm sure. OVPN connection is correct and stable. I simply can't go anywhere. I have double-checked static routes on pfsense and on router Everything here is fine.

    Funny thing is that I've managed to make all work with PFsense 1.2.3
    On PFsense 2 there is something different I can't understand.
    Any suggestion?

  • You should need more firewall rules on pfSense 2.0 than on 1.2.3.
    Double check those especially under OpenVPN tab.

  • It wasn't a problem connected with firewall rules!
    address pool (tunnel network):
    PFSense creates the interface ovpns1
    from ifconfig:
    ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::21d:9ff:fefb:54f0%ovpns1 prefixlen 64 scopeid 0x7
            inet –> netmask 0xffffffff
            nd6 options=3 <performnud,accept_rtadv>Opened by PID 22474

    No one is connected in VPN, so WHY is the interface UP?!?
    Why it uses subnet?!?
    If I connect with OVPN client, PFSense assigns to me, gw WHY?!?!
    It's not right at all! It seems really a BUG.
    Why does the interface ovpns1 stay always on?
    I've managed to make it work, but I have to configure a client override with tunnel network
    This way PFSense assigns to me, gw, and IT WORKS.
    However, no TUN interfaces area created!
    There's alway and only:
    ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::21d:9ff:fefb:54f0%ovpns1 prefixlen 64 scopeid 0x7
            inet --> netmask 0xffffffff
            nd6 options=3 <performnud,accept_rtadv>Opened by PID 22474</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast></performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>

  • Rebel Alliance Developer Netgate

    Most of that is just how OpenVPN works.

    ovpns1 is the tun interface. With PKI mode, the server side only ever shows one interface. The server's interface is always up. OpenVPN uses /30 networks out of your larger pool, one /30 for each client connection. The first client usually gets .6->.5 though, but that could be a client misconfiguration as well.

    You don't provide enough detail about your OpenVPN server config to speculate as to why you are seeing the other behaviors, but OpenVPN works correctly when properly configured.

  • The first client usually gets .6->.5 though, but that could be a client misconfiguration as well.

    That was the point: I was given .2->.1 and it didn't work.
    Unfortunately, I've deleted pfsense, so I can't paste my conf, but it was auto-generated by the wizard: no strange configuration, tun mode, tunnel network

    Without client override, server gave me>.1 (same address as ovpns1 interface) and it didn't obviously work.
    I had other openvpn server, but I'm not sure that they took the first /30 out of the address pool. I'm quite sure that they created different tun virtual interfaces, one for each connected client (tun0, tun1…)

    As far as my client conf is concerned, it is always the same: it didn't work without client override of the tunnel network.

    This is my client configuration:
    script-security 2
    port 1194
    remote XXX.XXX.XXX.XXX 1194
    dev tun
    tun-mtu 1500
    proto udp
    ca xxxx.crt
    cert xxxxx.crt
    key xxxxxxx.key
    dh xxxxxx.pem
    keepalive 10 120
    ns-cert-type server
    verb 3
    cipher AES-256-CBC
    auth SHA1

  • Rebel Alliance Developer Netgate

    The tun interface bit may be OS specific then but on FreeBSD, a PKI server only has one tun interface, and on 2.0 that is renamed, so it's always ovpns <number>where the number is the id of the vpn instance.

    I just went through the wizard, setup an OpenVPN instance, exported a config, and had a successful client connection with no problems, routing how I like.

    My client config is:

    dev tun
    proto udp
    cipher AES-128-CBC
    resolv-retry infinite
    remote 1209
    pkcs12 pfsense-udp-1209.p12
    tls-auth pfsense-udp-1209-tls.key 1

    And FYI, my /var/etc/openvpn/server1.conf

    dev ovpns1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/
    #user nobody
    #group nobody
    script-security 3
    keepalive 10 60
    proto udp
    cipher AES-128-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-config-dir /var/etc/openvpn-csc
    auth-user-pass-verify /var/etc/openvpn/server1.php via-env
    lport 1209
    management /var/etc/openvpn/server1.sock unix
    push "route"
    ca /var/etc/openvpn/ 
    cert /var/etc/openvpn/server1.cert 
    key /var/etc/openvpn/server1.key 
    dh /etc/dh-parameters.1024
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    push "route"

  • I tried again from scratch.
    Now it works.
    I wasn't even able to do firewall rules on ovpn tunnels. Now they match correctly.
    I tried to remember what I've done the previous time.
    The problem was probably related to a misleading tutorial that suggested to assign a new interface to ovpns1. I tried this conf but it didn't work. I rolled back, but I think that the conf has been hopeless corrupted.
    Thank you, you've been precious!

Log in to reply