4. PKI Site to Site does not work

PKI Site to Site does not work

  • P

    Hi there,

    I've been trying to setup a PKI Site 2 Site tunnel structure. This is needed due to a VoiP requirement (by Siemens) as all Client need to see each other.

    A static key scenario has been setup and was working fine - but phones connected to each satellite were and are not able to talk to each other.

    I've been following the post (http://forum.pfsense.org/index.php?topic=12888.0) to setup this PKI scenario… but still no joy.

    My setup looks like this:

    1) Server
    General:
    Network: 192.168.0.0/24
    Subnet: 255.255.255.0

    OpenVPN Server General:
    Protocol: UDP
    Local Port: 1196
    Address Pool: 10.0.11.0/24
    Client 2 Client: set
    Cryptography: BF-CBC
    Authentication method: PKI
    CA-Cert: filled with corresponding created key
    Server certificate: filled with corresponding created key
    Server key: filled with corresponding created key
    DH parameters: filled with correspo ???nding created key
    DHCP: no options set
    LZO: set
    Custom options: route 172.17.1.0 255.255.255.0;push "route 192.168.0.0 255.255.255.0"
    Description: site-to-site

    Client Specific (1):
    Common name: xxpf-01
    Custom options: iroute 172.17.1.0 255.255.255.0
    Description: 172.17.1.0/24

    Client Specific (2):
    Common name: xxpf-01
    Custom options: iroute 172.17.2.0 255.255.255.0
    Description: 172.17.2.0/24

    [Common name equals client.crt name]

    2) Client-01:
    General:
    Network: 172.17.1.0/24
    Subnet: 255.255.255.0

    Protocol: UDP
    Server address: 217.xxx.xxx.xxx
    Local Port: 1196
    Cryptography: BF-CBC
    Authentication method: PKI
    CA-Cert: filled with corresponding created key
    Client certificate: filled with corresponding created key
    Client key: filled with corresponding created key
    LZO compression: set
    Custom Options: none
    Description: xxpf-01

    1. Client-02:
      General:
      Network: 172.17.2.0/24
      Subnet: 255.255.255.0

    Protocol: UDP
    Server address: 217.xxx.xxx.xxx
    Local Port: 1196
    Cryptography: BF-CBC
    Authentication method: PKI
    CA-Cert: filled with corresponding created key
    Client certificate: filled with corresponding created key
    Client key: filled with corresponding created key
    LZO compression: set
    Custom Options: none
    Description: xxpf-02

    The tunnel from each remote site connects and is up and running… but

    1. It seems as if I can’t route traffic from Client-01 to Client-02
    2. I can’t use NetBIOS names – have to go for direct IPs. This is finw with me… but not for my users.

    Is there something I have not followed exactly? Where did I wrong within this configuration?

    Thank you in advance for your replies.

    Regards,
    Alexander

    ![PKI Site to Site.png](/public/imported_attachments/1/PKI Site to Site.png)
    ![PKI Site to Site.png_thumb](/public/imported_attachments/1/PKI Site to Site.png_thumb)

    0
  • B

    First, I presume that the common names for your two client are different and are not both "xxpf-01" as indicated.  If the CN for both clients are indeed the same, it will cause problems with your client-specific options (and therefore, could cause your routing issue).

    Have you allowed all traffic on your OpenVPN interface or do you some traffic blocked?  If you haven't specified anything on the interface, traffic will be blocked by default.

    NetBIOS names will not propagate a routed OpenVPN network (or any routed network for that matter).  NetBIOS name resolution require broadcasts to function and broadcasts won't cross networks.  Your two options to get NetBIOS name resolution to work are:

    1)  Setup a WINS server and point all clients towards it.
    2)  Use a bridged OpenVPN setup instead of a routed setup.

    0
  • Rebel Alliance Developer Netgate

    In the server custom config:

    Custom options should be:

    route 172.17.1.0 255.255.255.0;route 172.17.2.0 255.255.255.0;push "route 192.168.0.0 255.255.255.0";push "route 172.17.1.0 255.255.255.0";push "route 172.17.2.0 255.255.255.0";

    0
  • P

    Hello,

    @Boolah:

    First, I presume that the common names for your two client are different and are not both "xxpf-01" as indicated.  If the CN for both clients are indeed the same, it will cause problems with your client-specific options (and therefore, could cause your routing issue).

    Yes, it was a typo. "01" is "01" and "02" is "02".

    Have you allowed all traffic on your OpenVPN interface or do you some traffic blocked?  If you haven't specified anything on the interface, traffic will be blocked by default.

    Okay - Now it is getting interesting. Both remote pfSense's are behind a already existing home router. This could be various brand and models. Internet Connection is made with DHCP on both pfSense’s.

    In current example xxpf-01 is behind a Fritz.Box and gets IP 192.168.178.42. I see a few blocked connections on xxpf-01 firewall log…

    So what do I need to add here? Any tip or hint?

    Better go for IPSec with VPN Passthrough enabled on the employee Home Router (Fritz.Box)?

    NetBIOS names will not propagate a routed OpenVPN network (or any routed network for that matter).  NetBIOS name resolution require broadcasts to function and broadcasts won't cross networks.  Your two options to get NetBIOS name resolution to work are:

    1)  Setup a WINS server and point all clients towards it.
    2)  Use a bridged OpenVPN setup instead of a routed setup.

    On main site there is a WINS server running. I presume adding the option to OpenVPN Server should do the trick.

    Regards,
    Alexander

    0
  • P

    Hello,

    @jimp:

    In the server custom config:

    Custom options should be:

    route 172.17.1.0 255.255.255.0;route 172.17.2.0 255.255.255.0;push "route 192.168.0.0 255.255.255.0";push "route 172.17.1.0 255.255.255.0";push "route 172.17.2.0 255.255.255.0";

    Thank you. But I think, I am lost with the router / router setup mentioned in my reply above  :(

    0
  • Rebel Alliance Developer Netgate

    Without the options I mentioned, the two remote sites will never be able to talk to each others' subnets. I'd consider that a more urgent thing to fix.

    The other should be solved by setting a WINS server on the workstations that points to your existing WINS server. Note that this won't propagate to pfSense via OpenVPN, you'll need to set it in your DHCP server settings, or hardcode it on the workstations.

    0
  • P

    @jimp:

    Without the options I mentioned, the two remote sites will never be able to talk to each others' subnets. I'd consider that a more urgent thing to fix.

    The other should be solved by setting a WINS server on the workstations that points to your existing WINS server. Note that this won't propagate to pfSense via OpenVPN, you'll need to set it in your DHCP server settings, or hardcode it on the workstations.

    Yes - you are right… and I am not wasting my time with WINS nor NetBIOS. I would like to see those clients to able to speak to each other first. The rest I would consider as nice to have...

    I already added your route to the server config but it seems that I still struggle somehow. When I try to ping from 172.17.2.0/24 network (actually 172.17.2.248), I do get this:

    C:\Windows\System32>ping 172.17.1.1

    Ping wird ausgeführt für 172.17.1.1 mit 32 Bytes Daten:
    Antwort von 188.109.240.1: Zielnetz nicht erreichbar.
    Antwort von 188.109.240.1: Zielnetz nicht erreichbar.
    Antwort von 188.109.240.1: Zielnetz nicht erreichbar.
    Antwort von 188.109.240.1: Zielnetz nicht erreichbar.

    Ping-Statistik für 172.17.1.1:
        Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
        (0% Verlust),

    C:\Windows\System32>

    So where have I lost something here…. HELP!

    0
  • Rebel Alliance Developer Netgate

    Before you test from workstations, test from the router console or ssh.

    0
  • P

    Unfortunately the same..

    Enter an option: 7

    Enter a host name or IP address: 172.17.1.1

    PING 172.17.1.1 (172.17.1.1): 56 data bytes

    –- 172.17.1.1 ping statistics ---
    3 packets transmitted, 0 packets received, 100.0% packet loss

    Press ENTER to continue.

    0
  • P

    Addition

    From Console:

    60 bytes from dslb.pools.arcor-ip.net (188.109.240.1): Communication prohibited by filter
    Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
    4  5  00 5400 dc0f  0 0000  3e  01 ebcb 192.168.71.19  172.17.1.1

    I realy don't get it….

    The connection to the server directly is running well... but remote satellites  ???

    0
  • P

    Question:
    It seems as if I need to have OpenVPN in bridged mode to get my setup running. I followed this article (http://doc.pfsense.org/index.php/OpenVPN_Bridging) but again -> trapped.

    In my OpenVPN custom options I added this:

    dev tap0; float; server-bridge 192.168.0.1 255.255.255.0 192.168.0.160 192.168.0.199

    Unfortunately this does not work, I get this error message:

    openvpn[4446]: Options error: –server and --server-bridge cannot be used together

    Are there any other ways to get this up and running? I read sth. about the ashahi package. Could this be my solution?

    Regards,
    Alexander

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy