**Solved** Vlan and OpenVpn

[dexcs]

Hey Guys,

i tried to talk with some of you on irc, but still no luck at this problem:

Setup:

        WAN
            |
      .-----+------
      |  pfSense  |
      '-----+------
             |
         LAN      | 10.1.0.0/16 (VLAN ID 1 or none, Admin Network)
         OFFICE | 10.2.0.0/16 (VLAN ID 2)
         MEDIA  | 10.3.0.0/16 (VLAN ID 3)
             |
      .-----+----------------
      |  Internat Network |
      '-----+----------------
             |
             |
      .-----+-------------
      |  Synology NAS  |
      '-----+-------------
             |

So, i have a OpenVPN Server which should route to the office network only (Vlan 2, 10.2.x.x). It works all as expected, i can access devices inside the Office Network and they can ping openvpn clients.

The Problem is, the NAS can ping openvpn clients, but not the otherway round.
This is not true, i figured out that the ping goes through the wrong interface on the nas without any vlan id and the fw did not block it and routed it to the openvpn network. So i blocked pings from lan to openvpn.

For a better understanding:

• The NAS has 3 network cards, each plugged into the switch and connected to a single vlan. So the NAS has access to VLAN 1 to 3.
• LAN, Office and Media is the same physical port, OFFICE and MEDIA are virtual interfaces.
• The openvpn's network is 172.16.33.0/24

So here's what works and what not:

• NAS can access LAN / OFFICE / MEDIA without problems.
• NAS can access openvpn net without problems.
• OpenVPN Clients can access Office net without problems.
• OpenVPN Clients can not access the NAS.

Things i'm aware off:

• Firewall Rules are allowing all from Office to VPN and vice versa…
• Tunnel Network is set in the OVPN Settings

Does anyone have any idea on what to check now? I'm running out of ideas...

Thanks,
Max

[dexcs]

This thing is sooo strange… I have a wireshark dump here... but what does it tell??

It's a ssh connection attempt from the nas to a openvpn client...

step11.pcap
[Step11 seen from Firewall.pcap](/public/imported_attachments/1/Step11 seen from Firewall.pcap)

[johnpoz]

Tells me 10.2.1.10 sent 172.16.33.2 a syn, and that 172.168.33.2 sent back a syn,ack.

But seems 10.2.1.10 did not get this syn,ack because he resends the syn, so 172.16 keeps sending syn,ack

So you see here that 172.16 was sent the syn from mac A, but when he answers with is syn,ack he sends back to a different mac??  That doesn't seem right at all..  Points to possible asymmetrical routing.. Now those macs are only 1 off from each other.  So guess its possible your running sort of hsrp or something?  But it I doubt that??? More like Your nas is using a different gateway then where he got the traffic from.

Why does this nas have multiple interfaces in multiple networks?  That normally leads to trouble like this, and asymmetrical crap, etc.

[dexcs]

The NAS has 3 cables plugged into the switch. Each for one Vlan. 10.1 … 10.3...

So, you're right, the problem is the different macs and async routing... But why...

Holy crap... i got the problem...  in the dhcp server we did a static arp entry which pointed to the wrong mac (the first interface) and not to the mac of the second interface for the ip 10.2.1.10.

Thanks alot man!

[johnpoz]

"The NAS has 3 cables plugged into the switch. Each for one Vlan. 10.1 … 10.3..."

But why??  Makes no sense to be honest.. Can this nas supply 3 networks full pipe from its disk?  So you need to share the load across your different networks for performance?

This seems to over complicate the network.. I am more of a fan of KISS.. 1 device = 1 IP ;)

[dexcs]

Normally i would agree with you but part of the network is only 100 Mbit b/c of old cables and i see a performance increase if i use all them as separate ports… the network infrastructure get's rebuild next year and then i will hopefully get rid of this old junk :)

thanks for the help!

[johnpoz]

Ah.. Yeah and somewhat current nas disk should be easy to saturate a 100mbps network.. So sure if you need to share the load across multiple networks for performance, then yeah makes sense spread the load so you can get say 300mbps to move stuff to and from your disk as long as the clients are coming from different networks.

The only concern with such a network is possible asymmetrical or hairpins ;)

Glad you got it sorted.