.
Hello,
What I understood so far is that standard OpenVPN does not allow for client to client traffic.
Well, I have a NAS, working great, and I want to allow for certain clients to connect to each other.
client-to-client with a client_pf plugin is not going to be a option since Synology won`t build this for me (:
Reading up on routes and iptables I made a scheme and wrote down rules as best as I could with my understanding so far.
Routes are being set automatically by NAS/OpenVPN Package, so I no need to mess around with that, only allow/restrict who can connect to who. I`ve made ccd to work on the NAS, so clients get a static IP based on CommonName. Except for one client they all get dynamic IP`s from their LAN/WiFi.
I`ve spend a fair bit of time reading and writing down the rules to accept traffic between clients just to find out later that Synology did something that already allows for clients to see each other, big :o So I still not came to the point to test my config.
For example, connecting from one client-192.168.168.2 to a settop-box-192.168.168.6 is successful and I can watch TV on Android/Windows/etc. I`ve never discovered/noticed this because there was no need for client-to-client traffic but now my NAS is not at home anymore so this need arises. Probably I could rewrite the rules but first I would like to know for sure which "standard Synology rule(s)" is responsible for this and maybe a better solution is to delete that rule.
Although I have modified the config with regards to security, which somewhat ***** on these devices, the routes are still Synology standard.
Below is the output of iptables-save > rules.txt of the standard Synology rules:
*nat
: PREROUTING ACCEPT [29684:2336029]
: INPUT ACCEPT [12728:1222841]
: OUTPUT ACCEPT [18724:2689680]
: POSTROUTING ACCEPT [18696:2687552]
: DEFAULT_POSTROUTING - [0:0]
-A POSTROUTING -j DEFAULT_POSTROUTING
-A DEFAULT_POSTROUTING -s 192.168.168.0/24 -j MASQUERADE
COMMIT
*filter
: INPUT ACCEPT [98:5949]
: FORWARD ACCEPT [45:2545]
: OUTPUT ACCEPT [4580:1397341]
: DEFAULT_FORWARD - [0:0]
: DEFAULT_INPUT - [0:0]
: DOS_PROTECT - [0:0]
-A INPUT -j DOS_PROTECT
-A INPUT -j DEFAULT_INPUT
-A FORWARD -j DEFAULT_FORWARD
-A DEFAULT_FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A DEFAULT_FORWARD -m iprange --src-range 192.168.5.0-192.168.5.255 -j ACCEPT
-A DEFAULT_FORWARD -p udp -m udp --dport *vpnport* -j ACCEPT
-A DEFAULT_FORWARD -p tcp -m tcp --dport *vpnport* -j ACCEPT
-A DEFAULT_FORWARD -p tcp -m tcp --dport *sshport* -j ACCEPT
-A DEFAULT_INPUT -p tcp -m tcp --sport 53 -m length --length 2048:65535 -j DROP
-A DEFAULT_INPUT -p udp -m udp --sport 53 -m length --length 2048:65535 -j DROP
-A DEFAULT_INPUT -i lo -j ACCEPT
-A DEFAULT_INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A DEFAULT_INPUT -m iprange --src-range 192.168.5.0-192.168.5.255 -j ACCEPT
-A DEFAULT_INPUT -p udp -m udp --dport *vpnport* -j ACCEPT
-A DEFAULT_INPUT -p tcp -m tcp --dport *vpnport* -j ACCEPT
-A DEFAULT_INPUT -p tcp -m tcp --dport *sshport* -j ACCEPT
-A DEFAULT_INPUT -i bond0 -j DROP
-A DOS_PROTECT -i bond0 -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A DOS_PROTECT -i bond0 -p icmp -m icmp --icmp-type 8 -j DROP
-A DOS_PROTECT -i bond0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A DOS_PROTECT -i bond0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A DOS_PROTECT -i bond0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 10000/sec --limit-burst 100 -j RETURN
-A DOS_PROTECT -i bond0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
COMMIT
As far as I understand this rule
-A DEFAULT_POSTROUTING -s 192.168.168.0/24 -j MASQUERADE
gives clients access to the internet.
Shuffling data around I see that in the *nat table there is as good as no increase in packet flow.
In the DEFAULT_INPUT and OUTPUT, I see an increase but also in DEFAULT_FORWARD, that last one is confusing me.
The routing decision after PREROUTING should send it to INPUT or FORWARD but not both I think... :?:
Care to shed a :idea: on this?
.
