In order to seal off subscribers from each other in your network, but also be able to ping/ssh subscribers when administrating the YateUCN locally, the usage of iptables will help.
Depending on the settings of the tunnel, if the PDN tunnel has an explicit gateway (interface defined as x.x.x.x/nn/y.y.y.y) then it’s the gateway’s job to block access between subscribers.
If no explicit gateway is defined (interface defined as x.x.x.x/nn) you can use something like:
iptables -A FORWARD -i tun-pdn -o tun-pdn -j DROP
YateUCN
Unified LTE/GSM+GPRS core network, including SGSN, GGSN, GMSC, MME, SGW, PGW
See the product here ››
You will still be able to ping/ssh/etc from YateUCN as by default the local address selected towards subscribers will be x.x.x.x (owned by the tun-pdn interface itself).
Note that user plane packets will be routed by kernel’s “default” table, together with pretty much everything else.
When an explicit gateway is defined we install a policy routing rule separating user plane traffic:
tun_init_external=tun_config.sh “${tunnel}” “1400” “10.0.100.1/24/y.y.y.y”
# ip rule show
0: from all lookup local
150: from 10.0.100.1/24 lookup tun-pdn
32766: from all lookup main
32767: from all lookup default
# ip route show table tun-pdn
default via y.y.y.y dev enp0s31f6
# ip route show table local
…
broadcast 10.0.100.0 dev tun-pdn proto kernel scope link src 10.0.100.1
local 10.0.100.1 dev tun-pdn proto kernel scope host src 10.0.100.1
broadcast 10.0.100.255 dev tun-pdn proto kernel scope link src 10.0.100.1
All user packets go to y.y.y.y, the only exception is 10.0.100.1 which is routed by table “local” at highest priority.
