SOLVED Addition to iptables for openvpn w/TM3 running

[AndyInNYC]

I have a system on RentPBX with TM3 running.
Everything works correctly.

I'm now testing OpenVPN on the system and doing the install and configuration (and I don't want to kill my system).

My directions tell me to add a line to iptables and then do a "service iptables save" which, I seem to recall will blow up my TM3 settings - bad.

the line to be added is:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Can someone provide a translation which I can add to /etc/sysconfig/iptables?
Is this the correct table to change? What then?

Thanks all.

Andrew

 

[AndyInNYC]

Additionally, don't I need to open port 1194 (assuming that's my port) somewhere to allow the remote machine/phone into the system? Or does the certificate/being on the 10.8.0 subnet fix that?

Andrew

 

[AndyInNYC]

Sorry to keep at it, but I am stumped.
Anyone using VPN on a phone have any pointers?

Andrew

 

[rjaiswal]

Have you tried to use webmin to add the firewall rule?

 

[AndyInNYC]

I'm not sure that webmin is the problem; the problem is me <g>.

Given that travellin man is running, I am aware that it uses a 'static file' and then manipulates it to pull the dynamic dns info. I just can't find/remember if I still modify the /etc/sysconfig/iptables or some other table.

Additionally, I'm not sure of the syntax I should apply to the file (once I determine the right one) to 'translate' the line above into the correct format.

Lastly, I'm not sure if I need to/how to adjust port 1194 in iptables to allow the vpn connection to actually work.

So, I'm close, but without help I fear I'm not getting there.

Andrew

 

[howardsl2]

Let me try to help the OP...

Run the iptables command you mentioned, then edit /etc/sysconfig/iptables, find the section *nat, then add that iptables command starting with -A POSTROUTING... into that section, save the file.

If you are unable to connect to OpenVPN, add another rule to your iptables to open udp port 1194,

iptables -I INPUT -p udp --dport 1194 -s YOUR_IP -j ACCEPT

The -s YOUR_IP part is optional.

 

[AndyInNYC]

Almost, but not quite.

From the lack of log entries in my openvpn.log (as stated in server.conf) I'm thinking that my packets are getting dropped.

my iptables has an entry which reads:
-I INPUT -p udp --dport 1194
at the bottom below my last
-A INPUT -s XXX.XX.XX.XXX/Y -j ACCEPT which should be the addresses that should be always allowed. The last of these lines is for the VPN network:
-A INPUT 10.8.0.0/16 -j ACCEPT

the input is above the COMMIT line; following this COMMIT is "*mangle" and other entries as well

In the NAT section (below all of above) I have
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQERADE

and a last COMMIT

My server.conf file reads

local XXX.XXX.XXX.XXX
port 1194
proto udp
dev tun
mode server
server 10.8.0.0 255.255.255.0
push "route 10.2.1.0 255.255.255.0"
push "dhcp-option DNS 10.2.1.1"
keepalive 20 60
client-to-client
duplicate-cn
comp-lzo
verb 3
ca ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
log-append /etc/openvpn/openvpn.log

This code was copied from the Yealink VPN setup guide

The code that got dumped to the phone (T46G) is:

client
remote XXX.XXX.XXX.XXX
nobind
port 1194
proto udp
dev tun
comp-lzo
verb 3
ca /config/ca.crt
cert /config/client.crt
key /config/client.key

Again, this is from the Yealink OpenVPN guide

For further clarity, this is running on a RentPBX system (public IP - XXX.XXX.XXX.XXX) with iptables running to drop everything except the white list (TM3).

I feel I'm so close.

By the way, in the section "YOUR_IP" is that the RentPBX machine IP or the public IP where I'm connecting from. I didn't use it since it's optional, and if it is from my non-RentPBX machine it kind of defeats the purpose since I won't know all the IP's of the remote phones ahead of time.

Thanks so much for the help - I'd love to see if this solves my 'psychotic phones' issues with FIOS.


Andrew

 

[howardsl2]

Almost, but not quite.

From the lack of log entries in my openvpn.log (as stated in server.conf) I'm thinking that my packets are getting dropped.

my iptables has an entry which reads:
-I INPUT -p udp --dport 1194
at the bottom below my last
-A INPUT -s XXX.XX.XX.XXX/Y -j ACCEPT which should be the addresses that should be always allowed. The last of these lines is for the VPN network:
-A INPUT 10.8.0.0/16 -j ACCEPT

the input is above the COMMIT line; following this COMMIT is "*mangle" and other entries as well

In the NAT section (below all of above) I have
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQERADE

and a last COMMIT

My server.conf file reads

local XXX.XXX.XXX.XXX
port 1194
proto udp
dev tun
mode server
server 10.8.0.0 255.255.255.0
push "route 10.2.1.0 255.255.255.0"
push "dhcp-option DNS 10.2.1.1"
keepalive 20 60
client-to-client
duplicate-cn
comp-lzo
verb 3
ca ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
log-append /etc/openvpn/openvpn.log

This code was copied from the Yealink VPN setup guide

The code that got dumped to the phone (T46G) is:

client
remote XXX.XXX.XXX.XXX
nobind
port 1194
proto udp
dev tun
comp-lzo
verb 3
ca /config/ca.crt
cert /config/client.crt
key /config/client.key

Again, this is from the Yealink OpenVPN guide

For further clarity, this is running on a RentPBX system (public IP - XXX.XXX.XXX.XXX) with iptables running to drop everything except the white list (TM3).

I feel I'm so close.

By the way, in the section "YOUR_IP" is that the RentPBX machine IP or the public IP where I'm connecting from. I didn't use it since it's optional, and if it is from my non-RentPBX machine it kind of defeats the purpose since I won't know all the IP's of the remote phones ahead of time.

Thanks so much for the help - I'd love to see if this solves my 'psychotic phones' issues with FIOS.


Andrew

Double check that you have -j ACCEPT at the end of that udp 1194 rule.

If still not working you can post your entire iptables rules (iptables -nvL) to e.g. pastebin, with sensitive info removed. Then link it here so we can look at it.

 

[AndyInNYC]

Good news and bad <g>.

When I use the config I have from a Windows7 machine, I log in correctly.
The Yealink T46G still logs in from my local lan and shows a big red V as the OpenVPN status.

I'm thinking it could/should be the file location info, which is confusing from the various docs from Yealink. I'll keep trying various directory combinations until someone posts a working server/client conf file and a definitive ca /blah/blah/ca.crt listing.

I VERY MUCH appreciate the help. I did not have the -j ACCEPT at the end of the line after moving the line down to the bottom.

Andrew

 

[AndyInNYC]

So, on one hand, the phone has the V for VPN icon showing; one the other hand, it shows an IP of my local (remote) IP rather than the VPN IP.

I'm going to walk the phone over to a neighbor and see if it tunnels in.

Could someone post a working server.conf/vpn.cnf combo for a Yealink phone?

Andrew

 

[AndyInNYC]

OK, back from neighbor.

Red V icon came up, but the phone failed to register the account.

openvpn log reads:

Tue Jul 29 08:48:24 2014 NEIGHBORIP:55927 TLS: Initial packet from [AF_INET]NEIGHBORIP:55927, sid=ab70f45a e15fe557
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 VERIFY OK: depth=1, C=US, ST=CT, L=Wilton, O=Giuffre, OU=changeme, CN=changeme, name=changeme, $
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 VERIFY OK: depth=0, C=US, ST=CT, L=Wilton, O=Giuffre, OU=changeme, CN=client, name=changeme, em$
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Jul 29 08:48:27 2014 NEIGHBORIP:55927 [client] Peer Connection Initiated with [AF_INET]NEIGHBORIP:55927
Tue Jul 29 08:48:27 2014 client/NEIGHBORIP:55927 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Tue Jul 29 08:48:27 2014 client/NEIGHBORIP:55927 MULTI: Learn: 10.8.0.6 -> client/NEIGHBORIP:55927
Tue Jul 29 08:48:27 2014 client/NEIGHBORIP:55927 MULTI: primary virtual IP for client/NEIGHBORIP:55927: 10.8.0.6
Tue Jul 29 08:48:29 2014 client/NEIGHBORIP:55927 PUSH: Received control message: 'PUSH_REQUEST'
Tue Jul 29 08:48:29 2014 client/NEIGHBORIP:55927 send_push_reply(): safe_cap=940
Tue Jul 29 08:48:29 2014 client/NEIGHBORIP:55927 SENT CONTROL [client]: 'PUSH_REPLY,route 10.2.1.0 255.255.255.0,dhcp-option DNS 10.2.1.1$
Tue Jul 29 08:52:29 2014 client/NEIGHBORIP:55927 [client] Inactivity timeout (--ping-restart), restarting
Tue Jul 29 08:52:29 2014 client/NEIGHBORIP:55927 SIGUSR1[soft,ping-restart] received, client-instance restarting

Is there a line somewhere that I need to add to the PBX/iptables to 'tell' it that the IP address of the VPN should be allowed to register? I think I gave it access in iptables with:

-A INPUT -s 10.8.0.0/16 -j ACCEPT
but should that be 10.8.1.0 or anything else? It's a line I don't really understand fully.
On the PIAF front, should I be adding any 10.8.x.x (and which) anywhere to green-light it?
Andrew

 

[AndyInNYC]

Based on some Endpoint discussion pointers, I'm still lost.

I have made some changes to my server.conf and vpn.cnf (client) config files. The client now reads:

client
persist-tun
persist-key
cipher BF-CBC
auth SHA1
tls-client
ns-cert-type server
remote 209.159.159.231
nobind
port 1194
proto udp
dev tun
comp-lzo
verb 3
ca /config/openvpn/keys/ca.crt
cert /config/openvpn/keys/client.crt
key /config/openvpn/keys/client.key

The server.conf file now reads:

local 209.159.159.231
port 1194
proto udp
dev tun
# added based on pbxinaflash.com input
daemon
persist-tun
persist-key
cipher BF-CBC
tls-server
#end added
 
mode server
server 10.8.0.0 255.255.255.0
push "route 10.2.1.0 255.255.255.0"
push "dhcp-option DNS 10.2.1.1"
keepalive 20 60
client-to-client
duplicate-cn
comp-lzo
verb 3
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
log-append /etc/openvpn/openvpn.log

My log file indicates a connection. The Red V icon is lit on the phone.

The registration in 'sip show peers' is still the public IP of my office (not the RentPBX site or the VPN setting). This is the same as it has been; I fear that if I hook the phone up at the neighbor again I'll have the same failure.

In FreePBX's "Asterisk SIP Settings", I have NAT set to Yes, Static IP, External IP set to the RentPBX IP, and 'Local Networks' includes 10.8.0.2/255.255.255.255, 209.159.159.224/255.255.255.224, and 209.159.159.0/255.255.255.0

ifconfig on the RentPBX site shows:

eth0      Link encap:Ethernet  HWaddr AA:00:70:A3:21:01
          inet addr:RENTPBX_IP  Bcast:209.159.159.255  Mask:255.255.255.224
          inet6 addr: fe80::a800:70ff:fea3:2101/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:52568 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4235866 (4.0 MiB)  TX bytes:4335128 (4.1 MiB)
          Interrupt:17
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11647 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11647 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1484730 (1.4 MiB)  TX bytes:1484730 (1.4 MiB)
 
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1022 (1022.0 b)  TX bytes:0 (0.0 b)

So, my issue appears to be that the VPN functions on the phone and machine, but the registration reverts to my 'standard' way of connecting.

On the T46G I have the following settings:

Under Account -> Register, Outbound Proxy Server is diabled, Transport is UDP, NAT is set on Stun, stun server is set to stun.3cx.com.

Sip Server 1 is set to:

Server Host - RentPBX_IP Port 5060
Server Expires - 3600
Server Retry Counts 3


Any more follow up thoughts?


Andrew

 

[howardsl2]

Try changing that "Server Host" to 10.8.0.1, instead of "RentPBX_IP".

If still not working, you may also want to disable STUN in this case (first try without disabling)

 

[AndyInNYC]

Hwds12,

We seem to have a winner. I'll need to bring the phone outside my whitelisted IP, but 10.8.0.1 (and perhaps a few NAT or other changes) seems to have worked at least locally. I'll catalog my current settings and check.

Thank you so much. And assuming we have a working phone from a random IP, I'll be happy.

Now I need to find out if it will coexist with the evil 2Wire device in my boss' home office. The Mitel phones I have there just randomly ring, go off line, do weird things, etc.

Andrew

 

[wardmundy]

Have you tried to use webmin to add the firewall rule?

Just an FYI: Don't use WebMin to manage IPtables on systems running TM3 or newer Incredible PBX systems with preconfigured IPtables rules or you will do irreparable damage to the IPtables setup.

 

[AndyInNYC]

The phone came up at a neighbors house and placed a call to an outside #. I'll take that as a win.

Thanks everyone for your help!

The solution, since the phone was actually getting the Red V but not registering, was to change the Sip Server 1 IP to the RentPBX VPN IP (10.8.0.1).

Now I should rewrite their guide for everyone on here who needs a HOWTO without all my pain <g>.

Andrew

 

[wardmundy]

AndyInNYC: Yes, please!