Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSec clients can not access virtual box interfaces

    Scheduled Pinned Locked Moved IPsec
    4 Posts 3 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jarrod
      last edited by

      Running 2.2.5-RELEASE (amd64) on official hardware (SG-2220)

      Have IPsec VPN tunnel and it has been running for some time without any issues. But I have setup VirtualBox on a server and exposed the guest VM's (Centos and windows7) via a bridged interface so they appear on the LAN just like any other machine.  Internally everything works as expected.

      But for some reason the IPsec clients can not connect to any of the VM's.  Reviewing the pfsense logs shows nothing, no firewall blocks and noting in the IPsec logs.

      Interesting that the vpn clients can access the physical host that runs Virtual Box perfectly, and any other device that is on the network range, just not the virtual machines.

      Any suggestions ?

      VPN IPsec Phase 1:
      Key Exchange V1
      Encryption: AES 128bits
      Hash: SHA1
      DH group: 2 (1024bit)
      Lifetime: 28800
      DPD enabled

      Phase 2:
      Protocol: ESP
      Encryption: AES 128 bits
      Hash: SHA1
      PFS key group: off
      Lifetime: 3600

      On side A (LAN):
      192.168.5.0 /24

      On side B (Client):
      192.168.17.0 /24

      Firewall-Rule:
      Tab IPsec: Allow all IPv4 from all to everything.

      1 Reply Last reply Reply Quote 0
      • J
        jonathanbaird
        last edited by

        I've just tried this and I can access the VirtualBox VM's fine over my IPsec VPN. Could there be anything on your host machine blocking this such as a software firewall or anything?

        1 Reply Last reply Reply Quote 0
        • ?
          Guest
          last edited by

          via a bridged interface so they appear on the LAN just like any other machine.  Internally everything works as expected.

          Is this adapter doing anything likes NAT? Is this perhaps your problem?

          1 Reply Last reply Reply Quote 0
          • J
            jarrod
            last edited by

            Good suggestions.

            Below is the iptables output from the host that runs all the VM's. There are two address ranges in use here:
            192.168.5.0/24 which is the intended network, all devices should operate on this one ideally
            192.168.12.0/24 the second ip range created for the VM guests to operate in as a work around to this issue.
            192.168.122.0/24 I have not idea what this is, given the limited range I assume it would not be causing any issues.

            Does this seem correct?

            service iptables status
            Table: nat
            Chain PREROUTING (policy ACCEPT)
            num  target     prot opt source               destination         
            
            Chain POSTROUTING (policy ACCEPT)
            num  target     prot opt source               destination         
            1    MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535 
            2    MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535 
            3    MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24    
            
            Chain OUTPUT (policy ACCEPT)
            num  target     prot opt source               destination         
            
            Table: mangle
            Chain PREROUTING (policy ACCEPT)
            num  target     prot opt source               destination         
            
            Chain INPUT (policy ACCEPT)
            num  target     prot opt source               destination         
            
            Chain FORWARD (policy ACCEPT)
            num  target     prot opt source               destination         
            
            Chain OUTPUT (policy ACCEPT)
            num  target     prot opt source               destination         
            
            Chain POSTROUTING (policy ACCEPT)
            num  target     prot opt source               destination         
            1    CHECKSUM   udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:68 CHECKSUM fill 
            
            Table: filter
            Chain INPUT (policy ACCEPT)
            num  target     prot opt source               destination         
            1    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53 
            2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
            3    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67 
            4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:67 
            5    ACCEPT     udp  --  192.168.5.0/24       0.0.0.0/0           state NEW multiport dports 111,892,2049,32769 
            6    ACCEPT     tcp  --  192.168.5.0/24       0.0.0.0/0           state NEW multiport dports 111,892,2049,32803 
            
            Chain FORWARD (policy ACCEPT)
            num  target     prot opt source               destination         
            1    ACCEPT     all  --  0.0.0.0/0            192.168.122.0/24    state RELATED,ESTABLISHED 
            2    ACCEPT     all  --  192.168.122.0/24     0.0.0.0/0           
            3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
            4    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
            5    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
            
            Chain OUTPUT (policy ACCEPT)
            num  target     prot opt source               destination         
            
            
            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.