Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

IPCop VPN issue

  • 22-06-2005 8:12pm
    #1
    Registered Users, Registered Users 2 Posts: 3,889 ✭✭✭


    Is here the best place? Is Security forum better? Wasn't sure, but feel free to move...

    I'm using 2 IPCop v1.4.6 machines to establish a Net-to-Net VPN and am having connection stability issues....



    Connectivity: 2 DSL connections, one with fixed IP, the other with a semi permanent dynamic IP (fixed for the purposes of this exercise!)

    Networks/Firewalls:
    + ipcop1.domain.com - 192.168.10.0/255.255.255.0 - ipcop 1.4.6
    + ipcop2.domain.com - 192.168.33.0/255.255.255.0 - ipcop 1.4.6

    The 'domain' in the above domain names above have been substituted. Although they don't match the machine names, they are resolvable to the machine's Red IP in both cases.

    Steps in setup:
    + Click "Reset" to clear any certs, on both machines
    + Match time on both machines

    + On ipcop1:
    - Set Local VPN hostname to "ipcop1.domain.com"
    - Click on "Generate Root/Host Certificates"
    - Org name: "ipcop1", hostname="ipcop1.domain.com",
    and values for email/city/dept/etc.
    - Leave/ignore PKCS12 fields
    - Click on "Generate Root/Host Certificates"
    - Back on main screen download Host and Root certs
    prefixing the filenames with "ipcop1-"
    + On ipcop2:
    - Repeat above steps, substituting ipcop1 with ipcop2

    + On ipcop1, add new CA Cert:
    - CA Name="ipcop2"
    - Browse to "ipcop2-cacert.pem"
    - Click on "Upload CA Certificate"
    + Repeat above on ipcop2, substituting ipcop2 with ipcop1

    + Now I've root/host certs for both saved locally

    + On ipcop1:
    - "Add" new connection
    - Select "Net-to-Net", and click "Add" again
    - Name is "ipcop2", side="Left", local subnet=
    "192.168.10.0/255.255.255.0", remote host=
    "ipcop2.domain.com", remote subnet=
    "192.168.33.0/255.255.255.0"
    - Select "Upload a certificate", browse to local
    "ipcop2-hostcert.pem"
    - Leave "Enabled" tick, and leave everything else alone
    - Click "Save".
    + On ipcop2, repeat the above only:
    - Name="ipcop1", side="Right", local subnet=
    "192.168.33.0/255.255.255.0", remote host=
    "ipcop1.domain.com", remote subnet=
    "192.168.10.0/255.255.255.0"
    - Upload Certificate "ipcop1-hostcert.pem"

    + After refresh, both pages show the green "Open" status


    I can ping hosts from either side. However not from either firewall, just from client machines behind the firewall. I can start to access all services, however connections don't last very long. So, if I SCP, I get stalled after a second or 2. SSH session hang very shortly after login. HTTP transfers don't complete. At all times, pings are all OK, and none fail.In the advanced options for the connection, I haven't touched changed anything from the defaults. If I SSH port forward via the external address of the network, I don't experience any such connection issues. Pings are ~75ms between networks (interleaving is high on DSL here).

    ipsec.conf snip on ipcop1:
    conn ipcop2
    left=ipcop1.domain.com
    leftnexthop=%defaultroute
    leftsubnet=192.168.10.0/255.255.255.0
    leftcert=/var/ipcop/certs/hostcert.pem
    right=ipcop2.domain.com
    rightsubnet=192.168.33.0/255.255.255.0
    rightnexthop=%defaultroute
    rightcert=/var/ipcop/certs/ipcop2cert.pem
    dpddelay=30
    dpdtimeout=120
    dpdaction=hold
    authby=rsasig
    auto=start

    ipsec.conf snip on ipcop2:
    conn ipcop1
    right=ipcop2.domain.com
    rightsubnet=192.168.33.0/255.255.255.0
    rightnexthop=%defaultroute
    rightcert=/var/ipcop/certs/hostcert.pem
    left=ipcop1.domain.com
    leftsubnet=192.168.10.0/255.255.255.0
    leftnexthop=%defaultroute
    leftcert=/var/ipcop/certs/ipcop1cert.pem
    dpddelay=30
    dpdtimeout=120
    dpdaction=hold
    authby=rsasig
    auto=start

    route on ipcop1:
    Destination Gateway Genmask Flags Metric Ref Use Iface
    <ISP GW IP> * 255.255.255.255 UH 0 0 0 ppp0
    <ISP GW IP> * 255.255.255.255 UH 0 0 0 ipsec0
    192.168.33.0 <ISP GW IP> 255.255.255.0 UG 0 0 0 ipsec0
    1.1.1.0 * 255.255.255.0 U 0 0 0 eth1
    192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
    default <ISP GW IP> 0.0.0.0 UG 0 0 0 ppp0

    route on ipcop2:
    Destination Gateway Genmask Flags Metric Ref Use Iface
    <ISP GW IP> 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    <ISP GW IP> 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
    192.168.33.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    1.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
    192.168.10.0 <ISP GW IP> 255.255.255.0 UG 0 0 0 ipsec0
    0.0.0.0 <ISP GW IP> 0.0.0.0 UG 0 0 0 ppp0

    The <ISP GW IP> is a different IP (but same subnet) for each connection, and is not on the same subnet as the Red IP for each.


    In the logs I get log entries (similar on both ipcop machines), ...

    Jun 22 20:41:00 <hostname> pluto[17163]: packet from <other ipcop Red IP>:500: received Vendor ID payload [RFC 3947]
    Jun 22 20:41:00 <hostname> pluto[17163]: packet from <other ipcop Red IP>:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    Jun 22 20:41:00 <hostname> pluto[17163]: packet from <other ipcop Red IP>:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    Jun 22 20:41:00 <hostname> pluto[17163]: packet from <other ipcop Red IP>:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    Jun 22 20:41:00 <hostname> pluto[17163]: packet from <other ipcop Red IP>:500: received Vendor ID payload [Dead Peer Detection]
    Jun 22 20:41:00 <hostname> pluto[17163]: "ipcop2" #13: responding to Main Mode
    Jun 22 20:41:00 <hostname> pluto[17163]: "ipcop2" #13: transition from state (null) to state STATE_MAIN_R1
    Jun 22 20:41:00 <hostname> pluto[17163]: "ipcop2" #13: NAT-Traversal: Result using RFC 3947: no NAT detected
    Jun 22 20:41:00 <hostname> pluto[17163]: "ipcop2" #13: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2

    That "#13" increments and repeats those same lines again.

    Is the "NAT-Traversal: Result using RFC 3947: no NAT detected" line normal?
    Have I set it up right? (I get the exact same results using PSK instead of 509 certs)
    Anything else I can do to see why connections are dropping?

    Thanks, in advance, for any advice.. and thanks for taking the time to read this (if you got this far!!)

    .cg


Comments

  • Registered Users, Registered Users 2 Posts: 354 ✭✭AndrewMc


    cgarvey wrote:
    I can ping hosts from either side. However not from either firewall, just from client machines behind the firewall. I can start to access all services, however connections don't last very long. So, if I SCP, I get stalled after a second or 2. SSH session hang very shortly after login. HTTP transfers don't complete. At all times, pings are all OK, and none fail.In the advanced options for the connection, I haven't touched changed anything from the defaults. If I SSH port forward via the external address of the network, I don't experience any such connection issues. Pings are ~75ms between networks (interleaving is high on DSL here).

    Thanks, in advance, for any advice.. and thanks for taking the time to read this (if you got this far!!)

    Okay, I know absolutely nothing about IPCop, hence I only glanced over the config details and logs. But the fact that pings work and "large" transactions don't suggest to me a problem with MTU sizes. I know we had a problem with OpenVPN here between two Linux machines, and setting the MTU size down a bit (to 1400 I think) in the config file fixed everything for us. Can you see if there's any such option in IPCop?


  • Registered Users, Registered Users 2 Posts: 3,889 ✭✭✭cgarvey


    AndrewMc wrote:
    Okay, I know absolutely nothing about IPCop

    Because you were right, you didn't need to :)
    AndrewMc wrote:
    But the fact that pings work and "large" transactions don't suggest to me a problem with MTU sizes.

    Never even thought of that at all. I changed one side (my side) of it to 1400 and it wouldn't connect at all, then tried 1432 and all seems hunky dory so far. A few issues with Windows file sharing, but everything else that I really need is working fine.

    Ta muchly for the help.. you've saved me a lot of time!

    .cg


Advertisement