Open VPN server (not PBX integrated)

I am utilizing an OpenVPN server and client configuration to connect a remote computer to my network. The OpenVPN server is not the integrated version on the PBXact appliance. The server is an additional appliance. I have a PBXact 25 appliance. The local network at the office is 192.168.1.x, the VPN network is 128.10.0.x. I am able to connect to all other resources at the office from the remote machine through the VPN. However, I am not able to access any resources on the PBXact appliance from the remote network. I have put the VPN subnet into the firewall, responsive firewall, intrusion detection and asterisk SIP network. All without any desired change. Is there any where else that I can look to figure out why traffic is blocked coming from the additional local subnet?

128.10.0.x are valid public IP addresses assigned to Purdue University. Are you sure it’s not 10.128.0.x, which are normal RFC1918 (private) addresses that a VPN network might use?

Assuming that the remote computer’s normal LAN IP is other than 192.168.1.x, it receives a 128.10.0.x address from the VPN server, the server pushes a route to 192.168.1.x to the remote computer, the VPN server has a 192.168.1.x address on its hardware interface and it performs NAT, then it should all work (provided that the NAT implementation doesn’t interfere with SIP).

If you are doing some other kind of routing, please provide details.

I would troubleshoot in this order:

  1. Get ping from remote machine to PBX working.
  2. Get UCP (or PBXact admin) web access from remote machine working.
  3. Get voice calls working.

Running tcpdump on the PBX will capture incoming packets before any PBX software firewall(s) and outbound packets after any software firewalls. So, when testing ping, if the capture shows ICMP echo requests coming in but no responses going out, that’s a firewall issue and examining the iptables state should show why ICMP is being blocked.

OTOH, if the capture shows the incoming ICMP with a 128.10.0.x source address (no NAT), then the PBX (or your main router) would need to know how to route the response back to the VPN server, so it could transmit them through the tunnel.

Here is the section of the capture from the pbx when attempting to ping from the remote client:

OK, what does
iptables -vL
show?
Also, show any chains referenced that icmp would encounter.

Have you tried momentarily disabling iptables to see whether that helps?

Since this is non-NAT, if a response did get sent, how should it get back to the remote? Either the PBX needs to route 128.10.0.x to the VPN box, or the main router needs to do that.

I see what you are refering to in terms of the default VPN space being validated as an external space. It showed as such in the iptables output. I will modify that once I can get something working. On that note I am able to succesfully ping the other servers, workstations, and printers at the main office location. I am also able to rdp, connect to printers and map drives through the VPN from the same client machine that I am trying to connect to the PBX. That is what is leading me to focus on the issue being the PBX rejecting all packets not coming from the local 192.168.x.x subnet. I could be wrong though.

Since I am unable to upload the output document here is the output:

hain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
10M 1942M fpbxfirewall all – any any anywhere anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 72168 packets, 8952K bytes)
pkts bytes target prot opt in out source destination

Chain fpbx-rtp (1 references)
pkts bytes target prot opt in out source destination
1925K 446M ACCEPT udp – any any anywhere anywhere udp dpts:ndmp:dnp
13 1833 ACCEPT udp – any any anywhere anywhere udp dpts:terabase:hfcs-manager

Chain fpbxattacker (6 references)
pkts bytes target prot opt in out source destination
0 0 all – any any anywhere anywhere recent: SET name: ATTACKER side: source mask: 255.255.255.255
0 0 DROP all – any any anywhere anywhere

Chain fpbxblacklist (1 references)
pkts bytes target prot opt in out source destination

Chain fpbxfirewall (1 references)
pkts bytes target prot opt in out source destination
5359K 554M ACCEPT all – lo any anywhere anywhere
386K 619M ACCEPT tcp – any any anywhere anywhere state RELATED,ESTABLISHED
31 17732 ACCEPT icmp – any any anywhere anywhere
250K 22M ACCEPT all – any any anywhere 255.255.255.255
98624 16M ACCEPT all – any any anywhere anywhere PKTTYPE = multicast
0 0 ACCEPT udp – any any anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
4079K 731M fpbx-rtp all – any any anywhere anywhere
2154K 285M fpbxblacklist all – any any anywhere anywhere
2154K 285M fpbxsignalling all – any any anywhere anywhere
2154K 285M fpbxsmarthosts all – any any anywhere anywhere
2144K 280M fpbxregistrations all – any any anywhere anywhere
861K 45M fpbxnets all – any any anywhere anywhere
8173 651K fpbxhosts all – any any anywhere anywhere
8173 651K fpbxinterfaces all – any any anywhere anywhere
8173 651K fpbxreject all – any any anywhere anywhere
0 0 fpbxrfw all – any any anywhere anywhere mark match 0x2/0x2
8166 650K ACCEPT udp – any any anywhere anywhere state RELATED,ESTABLISHED
7 1405 fpbxlogdrop all – any any anywhere anywhere

Chain fpbxhosts (1 references)
pkts bytes target prot opt in out source destination
0 0 zone-trusted all – any any uc-97626691 anywhere

Chain fpbxinterfaces (1 references)
pkts bytes target prot opt in out source destination
0 0 zone-external all – eth0 any anywhere anywhere
8170 651K zone-external all – eth1 any anywhere anywhere

Chain fpbxknownreg (4 references)
pkts bytes target prot opt in out source destination
0 0 all – any any anywhere anywhere recent: REMOVE name: REPEAT side: source mask: 255.255.255.255
0 0 all – any any anywhere anywhere recent: REMOVE name: ATTACKER side: source mask: 255.255.255.255
1283K 235M ACCEPT all – any any anywhere anywhere mark match 0x1/0x1
12644 418K fpbxsvc-ucp all – any any anywhere anywhere
12644 418K fpbxsvc-zulu all – any any anywhere anywhere
12644 418K fpbxsvc-restapps all – any any anywhere anywhere
12644 418K fpbxsvc-restapps_ssl all – any any anywhere anywhere
12644 418K fpbxsvc-provis all – any any anywhere anywhere
12644 418K fpbxsvc-provis_ssl all – any any anywhere anywhere

Chain fpbxlogdrop (1 references)
pkts bytes target prot opt in out source destination
4 1300 DROP all – any any anywhere anywhere

Chain fpbxnets (1 references)
pkts bytes target prot opt in out source destination
0 0 zone-trusted all – any any 12.200.xxx.xxx anywhere
0 0 zone-trusted all – any any ip68-xxx-xxx-xxx.br.br.cox.net anywhere
852K 45M zone-trusted all – any any 192.168.10.0/24 anywhere
0 0 zone-trusted all – any any purdue-cs-en.cs.purdue.edu/24 anywhere

Chain fpbxratelimit (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – any any anywhere anywhere mark match 0x4/0x4
0 0 ACCEPT all – any any anywhere anywhere recent: CHECK seconds: 90 hit_count: 1 name: WHITELIST side: source mask: 255.255.255.255
0 0 all – any any anywhere anywhere state NEW recent: SET name: REPEAT side: source mask: 255.255.255.255
0 0 all – any any anywhere anywhere state NEW recent: SET name: DISCOVERED side: source mask: 255.255.255.255
0 0 LOG all – any any anywhere anywhere LOG level warning
0 0 fpbxattacker all – any any anywhere anywhere recent: CHECK seconds: 86400 hit_count: 1 name: ATTACKER side: source mask: 255.255.255.255
0 0 fpbxattacker all – any any anywhere anywhere recent: CHECK seconds: 86400 hit_count: 100 name: REPEAT side: source mask: 255.255.255.255
0 0 fpbxattacker all – any any anywhere anywhere recent: CHECK seconds: 3600 hit_count: 50 name: REPEAT side: source mask: 255.255.255.255
0 0 fpbxshortblock all – any any anywhere anywhere recent: CHECK seconds: 60 hit_count: 10 name: REPEAT side: source mask: 255.255.255.255
0 0 ACCEPT all – any any anywhere anywhere

Chain fpbxregistrations (1 references)
pkts bytes target prot opt in out source destination
334K 61M fpbxknownreg all – any any 192.168.10.109 anywhere
300K 53M fpbxknownreg all – any any 192.168.10.115 anywhere
297K 59M fpbxknownreg all – any any 192.168.10.113 anywhere
365K 62M fpbxknownreg all – any any 192.168.10.118 anywhere

Chain fpbxreject (1 references)
pkts bytes target prot opt in out source destination
8170 651K rejsvc-nfs all – any any anywhere anywhere
8170 651K rejsvc-smb all – any any anywhere anywhere

Chain fpbxrfw (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – any any anywhere anywhere recent: CHECK seconds: 90 hit_count: 1 name: WHITELIST side: source mask: 255.255.255.255
0 0 all – any any anywhere anywhere recent: SET name: REPEAT side: source mask: 255.255.255.255
0 0 all – any any anywhere anywhere recent: SET name: DISCOVERED side: source mask: 255.255.255.255
0 0 fpbxattacker all – any any anywhere anywhere recent: CHECK seconds: 10 hit_count: 50 name: REPEAT side: source mask: 255.255.255.255
0 0 fpbxattacker all – any any anywhere anywhere recent: CHECK seconds: 86400 hit_count: 1 name: ATTACKER side: source mask: 255.255.255.255
0 0 fpbxshortblock all – any any anywhere anywhere recent: CHECK seconds: 60 hit_count: 10 name: SIGNALLING side: source mask: 255.255.255.255
0 0 all – any any anywhere anywhere recent: SET name: SIGNALLING side: source mask: 255.255.255.255
0 0 fpbxattacker all – any any anywhere anywhere recent: CHECK seconds: 86400 hit_count: 100 name: REPEAT side: source mask: 255.255.255.255
0 0 ACCEPT all – any any anywhere anywhere

Chain fpbxshortblock (2 references)
pkts bytes target prot opt in out source destination
0 0 all – any any anywhere anywhere recent: SET name: CLAMPED side: source mask: 255.255.255.255
0 0 REJECT all – any any anywhere anywhere reject-with icmp-port-unreachable

Chain fpbxsignalling (1 references)
pkts bytes target prot opt in out source destination
1283K 235M MARK udp – any any anywhere anywhere udp dpt:5160 MARK set 0x3
10409 5052K MARK udp – any any anywhere anywhere udp dpt:sip MARK set 0x3

Chain fpbxsmarthosts (1 references)
pkts bytes target prot opt in out source destination
10409 5052K ACCEPT all – any any 1.1.2.1 anywhere mark match 0x1/0x1

Chain fpbxsvc-chansip (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:5160

Chain fpbxsvc-ftp (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ftp

Chain fpbxsvc-http (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:dc

Chain fpbxsvc-https (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:https

Chain fpbxsvc-iax (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:iax

Chain fpbxsvc-isymphony (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:58080
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:55050

Chain fpbxsvc-letsencrypt (0 references)
pkts bytes target prot opt in out source destination

Chain fpbxsvc-nfs (0 references)
pkts bytes target prot opt in out source destination

Chain fpbxsvc-pjsip (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:sip

Chain fpbxsvc-provis (4 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ctf

Chain fpbxsvc-provis_ssl (3 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:powerclientcsf

Chain fpbxsvc-restapps (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:xfer

Chain fpbxsvc-restapps_ssl (1 references)
pkts bytes target prot opt in out source destination

Chain fpbxsvc-smb (0 references)
pkts bytes target prot opt in out source destination

Chain fpbxsvc-ssh (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ssh

Chain fpbxsvc-tftp (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:tftp

Chain fpbxsvc-ucp (4 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:81
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:vcom-tunnel
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:mcreport

Chain fpbxsvc-vpn (3 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:openvpn

Chain fpbxsvc-webrtc (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:radan-http
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:8089

Chain fpbxsvc-xmpp (3 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:xmpp-client

Chain fpbxsvc-zulu (4 references)
pkts bytes target prot opt in out source destination
0 0 fpbxratelimit tcp – any any anywhere anywhere tcp dpt:teradataordbms

Chain rejsvc-nfs (1 references)
pkts bytes target prot opt in out source destination

Chain rejsvc-smb (1 references)
pkts bytes target prot opt in out source destination

Chain zone-external (2 references)
pkts bytes target prot opt in out source destination
0 0 all – any any anywhere anywhere mark match 0x10/0x10
8170 651K fpbxsvc-ucp all – any any anywhere anywhere
8170 651K fpbxsvc-zulu all – any any anywhere anywhere
8170 651K fpbxsvc-provis all – any any anywhere anywhere
8170 651K fpbxsvc-vpn all – any any anywhere anywhere
8170 651K fpbxsvc-xmpp all – any any anywhere anywhere

Chain zone-internal (0 references)
pkts bytes target prot opt in out source destination
0 0 all – any any anywhere anywhere mark match 0x4/0x4
0 0 fpbxsvc-ssh all – any any anywhere anywhere
0 0 fpbxsvc-http all – any any anywhere anywhere
0 0 fpbxsvc-https all – any any anywhere anywhere
0 0 fpbxsvc-ucp all – any any anywhere anywhere
0 0 fpbxsvc-pjsip all – any any anywhere anywhere
0 0 fpbxsvc-chansip all – any any anywhere anywhere
0 0 fpbxsvc-iax all – any any anywhere anywhere
0 0 fpbxsvc-webrtc all – any any anywhere anywhere
0 0 fpbxsvc-zulu all – any any anywhere anywhere
0 0 fpbxsvc-isymphony all – any any anywhere anywhere
0 0 fpbxsvc-provis all – any any anywhere anywhere
0 0 fpbxsvc-provis_ssl all – any any anywhere anywhere
0 0 fpbxsvc-vpn all – any any anywhere anywhere
0 0 fpbxsvc-restapps all – any any anywhere anywhere
0 0 fpbxsvc-xmpp all – any any anywhere anywhere
0 0 fpbxsvc-ftp all – any any anywhere anywhere
0 0 fpbxsvc-tftp all – any any anywhere anywhere

Chain zone-other (0 references)
pkts bytes target prot opt in out source destination
0 0 all – any any anywhere anywhere mark match 0x8/0x8
0 0 fpbxsvc-ucp all – any any anywhere anywhere
0 0 fpbxsvc-zulu all – any any anywhere anywhere
0 0 fpbxsvc-provis all – any any anywhere anywhere
0 0 fpbxsvc-provis_ssl all – any any anywhere anywhere
0 0 fpbxsvc-vpn all – any any anywhere anywhere
0 0 fpbxsvc-xmpp all – any any anywhere anywhere

Chain zone-trusted (5 references)
pkts bytes target prot opt in out source destination
852K 45M ACCEPT all – any any anywhere anywhere

Sorry, I don’t understand what is happening. I know nothing about PBXact and perhaps there is something unusual about the hardware setup.

I hope that someone more knowledgeable will continue this thread.

It seems to me that when the incoming ICMP packet as captured by tcpdump hits the INPUT chain, it immediately goes to the fpbxfirewall chain. There, the first two entries don’t match and the third should ACCEPT the packet. The OUTPUT chain has no rules, so the reply also shouldn’t be blocked. Yet we don’t see replies in the capture.

You could try temporarily stopping iptables to see whether that makes a difference.

I don’t understand why the capture shows “Linux cooked capture”; I would assume that you’d be capturing directly from a hardware Ethernet interface (line after “Frame 84” should show Ethernet II and the associated MAC addresses).

Also, assuming that it’s normal for packets emitted from the VPN box to have source addresses 128.10.0.x, how do replies get back to that box (when successfully accessing a host other than the PBX)? I would think that either the host would need a static route for 128.10.0.0/24 to the VPN box, or the main router would need such a route. How was this accomplished?

The appliance is a firewall/vpn router. Routing works fine for all devices except the pbx. Ping works both ways from the internal subnet to the vpn subnet and vice versa. The only device I am having issues with is the pbx. There does seem to be something not right with the networking/routing on the pbx side. I am just not familiar enough with it. I have had two consultants remote into the system and verified the setup is correct. They stated the issue has to be with the network equipment. I dont see how that could be if everything else works 100% except for the pbx.

There is something going on that the pbx gui interface is not displaying. I just dont know yet what.

OK, that explains how packets with destination address 128.10.0.x sent from a working host to the main router make it to the VPN tunnel.

Please post the output on the PBX for
ifconfig -a
and
route -n

Also, please confirm that for the Wireshark capture in your earlier post, you ran tcpdump as root on the PBX and copied the .pcap file to another machine for analysis with Wireshark.

Correct, I ran the tcpdump on the pbx device and loaded the file on a client machine in wireshark.

Here is the output for ifconfig. Ethernet 0 is connected to the network. Ethernet 1 is a direct connection to the ATT equipment, peer/partner connection for the SIP trunk. Ethernet 2 and 3 are not utilized.

th0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::290:27ff:fef0:5b3a prefixlen 64 scopeid 0x20
ether 00:90:27:f0:5b:3a txqueuelen 1000 (Ethernet)
RX packets 4669747 bytes 732012876 (698.1 MiB)
RX errors 0 dropped 89 overruns 0 frame 0
TX packets 1655548 bytes 513907805 (490.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xd0900000-d0920000

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 1.1.xxx.xxx netmask 255.255.255.0 broadcast 1.1.xxx.xxx
inet6 fe80::290:27ff:fef0:5b3b prefixlen 64 scopeid 0x20
ether 00:90:27:f0:5b:3b txqueuelen 1000 (Ethernet)
RX packets 1463878 bytes 960806374 (916.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1470931 bytes 278650435 (265.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17 memory 0xd0800000-d0820000

eth2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:90:27:f0:5b:3c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 memory 0xd0700000-d0720000

eth3: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 00:90:27:f0:5b:3d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19 memory 0xd0600000-d0620000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 6216122 bytes 627106018 (598.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6216122 bytes 627106018 (598.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

here is the route information:

eKernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 1.1.xxx.xxx 0.0.0.0 UG 0 0 0 eth1
1.1.xxx.xxx 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

So your default route is via eth1. The ping replies went to the AT&T gear and (presumably) were sent to Purdue :slight_smile:

Change it to use eth0 and you should be good to go.

That was it. Everything else should fall into place now. Thank you is an understatement. I really appreciate the time you spent going through this with me.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.