[SOLVED] Troubles with Site-to-Site

This forum is for admins who are looking to build or expand their OpenVPN setup.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
thompson
OpenVpn Newbie
Posts: 18
Joined: Mon Jan 27, 2014 5:39 am

[SOLVED] Troubles with Site-to-Site

Post by thompson » Mon Aug 01, 2022 6:31 pm

Been bashing my head against the wall for a few days now trying to get this figured out, sure it's something simple I'm overlooking, any outside input would be greatly appreciated.

End goal is to be able to easily access the LAN on either side of a Server-Client/Gateway setup.

Image
Network Notepad Free Ed.

Currently, I'm having what I think are routing or iptable/UFW issues.

From Desktop:
Can ping the Cisco and SSH the R-Pi, nothing else

From OVPN Server:
Can freely ping and access anything on both LAN

From Work LAN:
Can ping & access either LAN freely (it wouldn't earlier, not sure what I changed to get it working)

From phone on 4G+VPN:
Can ping and access either LAN freely

I've mostly been messing about with iptables/UFW, thinking that's where the issue seems to lay, but no clue. Seeing as the OVPN server has free access & responds to Work LAN, I'm assuming at least the routing on the Cisco is good? I have no custom routing on the Desktop/S9 either so the ER-X routes seem to work as well, given they can ping the R-Pi & Cisco.

server.conf
server 192.168.191.0 255.255.255.0
port 110
proto udp
dev tun
topology subnet
route 192.168.0.0 255.255.255.0 192.168.191.1

ca ca.crt
cert server.crt
key server.key
dh dh2048.pem

ifconfig-pool-persist ipp.txt
client-config-dir ccd
client-to-client
keepalive 10 60
cipher AES-128-CBC
user nobody
group nogroup
persist-key
persist-tun

push "dhcp-option DNS 192.168.192.99"
push "dhcp-option WINS 192.168.192.99"

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

status openvpn-status.log
verb 4


CCD for R-Pi:

Code: Select all

iroute 192.168.0.0 255.255.255.0
ifconfig-push 192.168.191.6 255.255.255.0
push "route 192.168.192.0 255.255.255.0"
Server iptables-save dump:

Code: Select all

-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N ICMP
-N TCP
-N UDP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A UDP -p tcp -m tcp --dport 110 -j ACCEPT
client
client
dev tun
proto udp
remote DDNS_HERE 110 udp
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert workpi.crt
key workpi.key
remote-cert-tls server
cipher AES-128-CBC
verb 4
auth-nocache


R-Pi iptables-save dump:

Code: Select all

*filter
# Allow all outgoing, but drop incoming and forwarding packets by default
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Custom per-protocol chains
:UDP - [0:0]
:TCP - [0:0]
:ICMP - [0:0]

# Acceptable UDP traffic
-A UDP -p udp --dport 110 -j ACCEPT
#-A UDP -p udp --dport 53 -j ACCEPT

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT
#-A TCP -p tcp --dport 53 -j ACCEPT

# Acceptable ICMP traffic

# Boilerplate acceptance policy
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Pass traffic to protocol-specific chains
## Only allow new connections (established and related should already be handled)
## For TCP, additionally only allow new SYN packets since that is the only valid
## method for establishing a new TCP connection
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

# User added whatever
-A FORWARD -i tun0 -o eth0 -j ACCEPT
-A INPUT -s 192.168.192.0/24 -j ACCEPT
-A INPUT -s 192.168.191.0/24 -j ACCEPT
#-A INPUT -s 192.168.0.0/24 -j ACCEPT

# Reject anything that's fallen through to this point
## Try to be protocol-specific w/ rejection message
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

# Commit the changes
COMMIT

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
Last edited by thompson on Tue Aug 02, 2022 4:21 am, edited 3 times in total.

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: Troubles with Site-to-Site

Post by openvpn_inc » Mon Aug 01, 2022 11:20 pm

First, get rid of ufw, it makes things unnecessarily complicated. What is it supposed to "protect" you from? Set up rules to limit your access after you have gotten it to work, and then without ufw.

Second, typo in your diagram: you did not show your openvpn server as having an address in the VPN. According to your config, it would be 192.168.191.1.

I'm not going to put much time in this. I suspect that by getting rid of ufw on both sides, you'll be fine. But there might be other typos lurking; we can look again without ufw.

regards, rob0
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

thompson
OpenVpn Newbie
Posts: 18
Joined: Mon Jan 27, 2014 5:39 am

Re: Troubles with Site-to-Site

Post by thompson » Tue Aug 02, 2022 12:20 am

Okay noted :lol:

Gutted UFW out, cleansed iptables to default squeaky clean and put in the bare minimum so I know I can keep connectivity (office isn't far away but still a PITA to have to go down). I did install iptables-persistent, any issues I should know of there?

Updated the OP to reflect the changes.

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: Troubles with Site-to-Site

Post by openvpn_inc » Tue Aug 02, 2022 3:10 am

Main thing you should know is that iptables is only needed to block packets, and since your VPN endpoints are both behind firewalls at their respective sites, you don't really need any rules. Just say ACCEPT.

Yes, iptables-persistent is the Debian thing for restoring rules after boot.

What's not working now? Probably something you are rejecting. No firewalls, no sadness. Tighten it up later if you want, but only after you have everything you need working.

regards, rob0
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

thompson
OpenVpn Newbie
Posts: 18
Joined: Mon Jan 27, 2014 5:39 am

Re: Troubles with Site-to-Site

Post by thompson » Tue Aug 02, 2022 4:04 am

Yeah if I didn't make it obvious firewalls not exactly my strong suite heh.

I backed it way off, just accept policies, though on the Client/Gateway I do seem to need the masquerade part of NAT, or I lose the ability to ping a few of the devices on the Work LAN, unless I've got something wrong elsewhere.

Same issue though persists, I can only very selectively communicate with Work LAN from Home LAN with exception to the OVPN Server itself (it can at leas ping, but if it weren't headless I'd reckon it could navigate to the webGUI etc I'm chasing). This is why I was going the iptables route as it seems to be deadheading there.

thompson
OpenVpn Newbie
Posts: 18
Joined: Mon Jan 27, 2014 5:39 am

Re: Troubles with Site-to-Site

Post by thompson » Tue Aug 02, 2022 4:21 am

I added the NAT Postrouting bit back to the Client/Gateway and it verks!

So this was one of the stubborn IPs that I couldn't ping nor access.

Code: Select all

Tracing route to 192.168.0.104 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.192.99
  2   105 ms   101 ms   102 ms  192.168.191.6
  3   102 ms    98 ms   105 ms  192.168.0.104

Trace complete.
WebGUI immediately popped up as well (it's one of the printers at the office, I've just been going after it's IP as it's easy lol).

I messed up one of the prime directives, KISS...keep it simple stoopid!

Though, I didn't even have UFW enabled when I started all this, but looking at the state iptables was in before you suggested I restore it...why am I not surprised it wasn't working.

TY TY TY Rob!

Post Reply