Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
On Fri, 2015-02-20 at 06:03 +, Chuck Mariotti wrote: You could try TCP for the OpenVPN if the phones will support it. The vast majority of your traffic will be UDP so you wont get the joy of TCP in TCP exponential standoffs. Cheers Jon The phones do support TCP (an option on a per line basis offers UDP/TCP). Could you clarify what you mean by this exactly? A little bit confused... It seems the OpenVPN connections are up/down... so you are suggesting to switch the OpenVPN connection to TCP instead of UDP? Keep the phone UDP? The standoffs you suggest, are they the OpenVPN or the Phone data screwing up? Or both? Chuck ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold Chuck TCP, for example, an RDP session or ssh within a TCP tunnel *can* show horrible performance because TCP has a built in standoff mechanism (can't remember the name). If you have TCP within TCP then the effect of both trying to fix up a dodgy connection can quickly cause an exponential standoff. This will manifest itself as the tunnel seeming to freeze for 5-20 seconds and then carrying on. As you would be putting UDP traffic which is fire and forget through a TCP OpenVPN the above effect wont happen. However because OVPN would use TCP then it will cause the NAT session to be held open, which may fix the problem that you are having. So, change the OpenVPN server to listen on TCP (same port if you like). Also change the firewall rule on WAN for TCP and change the phones to connect using TCP. Cheers Jon ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
That's definitely the cable modem's NAT getting confused. If you can get the phones to randomize their source ports on their OpenVPN traffic, that might resolve. I'm not sure if that's possible on those phones. In stock OpenVPN, specifying lport 0 in the config will make it choose a random port. I'm not sure if that's configurable for the Yealink phones though. We disable that automatically in our OpenVPN client export for Yealink because they didn't support it at least up until recently. If you can change the modem to bridge mode to pass through the public IP to a router of some sort that will properly handle that circumstance, it'll resolve that. That might be hit or miss with consumer-grade routers. A completely default pfSense config will work fine in that circumstance, as it'll randomize the source ports on its own so the phones don't have to. I'm not sure installing a pfSense box is an option at the moment... will a consumer grade (Asus RT-AC68U as an example) be useful? Unless there is a Just as good / same price pfSense with wifi AC). I have one ASUS pulled from an installation... I guess another approach could be to use the consumer router to build the OpenVPN tunnel instead of the phones. Not sure if that's better or worse... will have to think that through... it's nice to see the phones popup on pfSense. Regards, Chuck ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
On 19 February 2015 at 14:51, Chuck Mariotti cmario...@xunity.com wrote: That's definitely the cable modem's NAT getting confused. If you can get the phones to randomize their source ports on their OpenVPN traffic, that might resolve. I'm not sure if that's possible on those phones. In stock OpenVPN, specifying lport 0 in the config will make it choose a random port. I'm not sure if that's configurable for the Yealink phones though. We disable that automatically in our OpenVPN client export for Yealink because they didn't support it at least up until recently. If you can change the modem to bridge mode to pass through the public IP to a router of some sort that will properly handle that circumstance, it'll resolve that. That might be hit or miss with consumer-grade routers. A completely default pfSense config will work fine in that circumstance, as it'll randomize the source ports on its own so the phones don't have to. I'm not sure installing a pfSense box is an option at the moment... will a consumer grade (Asus RT-AC68U as an example) be useful? Unless there is a Just as good / same price pfSense with wifi AC). I have one ASUS pulled from an installation... I guess another approach could be to use the consumer router to build the OpenVPN tunnel instead of the phones. Not sure if that's better or worse... will have to think that through... it's nice to see the phones popup on pfSense. I would build the tunnel using other devices and just let the phones communicate. It's a lot easier that way. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
You could try TCP for the OpenVPN if the phones will support it. The vast majority of your traffic will be UDP so you wont get the joy of TCP in TCP exponential standoffs. Cheers Jon The phones do support TCP (an option on a per line basis offers UDP/TCP). Could you clarify what you mean by this exactly? A little bit confused... It seems the OpenVPN connections are up/down... so you are suggesting to switch the OpenVPN connection to TCP instead of UDP? Keep the phone UDP? The standoffs you suggest, are they the OpenVPN or the Phone data screwing up? Or both? Chuck ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
Ya, I am testing that in lab now with an Asus rt-ac68u I have. Going to see what behavior is for disconnects, etc... Will also have to figure out how to remote into the phones and the rules, etc... From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Odhiambo Washington Sent: February-19-15 8:04 AM To: pfSense Support and Discussion Mailing List Subject: Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues On 19 February 2015 at 14:51, Chuck Mariotti cmario...@xunity.commailto:cmario...@xunity.com wrote: That's definitely the cable modem's NAT getting confused. If you can get the phones to randomize their source ports on their OpenVPN traffic, that might resolve. I'm not sure if that's possible on those phones. In stock OpenVPN, specifying lport 0 in the config will make it choose a random port. I'm not sure if that's configurable for the Yealink phones though. We disable that automatically in our OpenVPN client export for Yealink because they didn't support it at least up until recently. If you can change the modem to bridge mode to pass through the public IP to a router of some sort that will properly handle that circumstance, it'll resolve that. That might be hit or miss with consumer-grade routers. A completely default pfSense config will work fine in that circumstance, as it'll randomize the source ports on its own so the phones don't have to. I'm not sure installing a pfSense box is an option at the moment... will a consumer grade (Asus RT-AC68U as an example) be useful? Unless there is a Just as good / same price pfSense with wifi AC). I have one ASUS pulled from an installation... I guess another approach could be to use the consumer router to build the OpenVPN tunnel instead of the phones. Not sure if that's better or worse... will have to think that through... it's nice to see the phones popup on pfSense. I would build the tunnel using other devices and just let the phones communicate. It's a lot easier that way. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
On Wed, 2015-02-18 at 06:38 +, Chuck Mariotti wrote: That's definitely the cable modem's NAT getting confused. If you can get the phones to randomize their source ports on their OpenVPN traffic, that might resolve. I'm not sure if that's possible on those phones. In stock OpenVPN, specifying lport 0 in the config will make it choose a random port. I'm not sure if that's configurable for the Yealink phones though. We disable that automatically in our OpenVPN client export for Yealink because they didn't support it at least up until recently. If you can change the modem to bridge mode to pass through the public IP to a router of some sort that will properly handle that circumstance, it'll resolve that. That might be hit or miss with consumer-grade routers. A completely default pfSense config will work fine in that circumstance, as it'll randomize the source ports on its own so the phones don't have to. Thanks Chris, I've emailed Yealink support but it seems they are off until mid-next week (Chinese New Year). Not sure what to do, purchase a 3rd party router to see if solves the problem or if I should wait to see what Yealink's answer is first. Reading up on the modem seems like bridge mode is a little problematic... maybe a call to the cable provider first to see options. Thanks Again, Chuck Chuck You could try TCP for the OpenVPN if the phones will support it. The vast majority of your traffic will be UDP so you wont get the joy of TCP in TCP exponential standoffs. Cheers Jon ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
I have 4 Yealink T46G phones, 3 on one network (problematic), 1 on a separate network... all phones are OpenVPNing into pfSense box at datacenter... then using a phone system through the OpenVPN connection. The problematic location keeps having issues with phones not receiving calls or making calls... as well as call quality issues. Rebooting the phones solves the problems. The OpenVPN logs contain a number of TLS Errors (TLS keys are out of sync)... as well as Auth/Decript errors (packet HMAC authentication failed). Logs are below. Can anyone shed some light on what might be happening here? Regards, Chuck ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
On Tue, Feb 17, 2015 at 9:50 PM, Chuck Mariotti cmario...@xunity.com wrote: I have 4 Yealink T46G phones, 3 on one network (problematic), 1 on a separate network… all phones are OpenVPNing into pfSense box at datacenter… then using a phone system through the OpenVPN connection. The problematic location keeps having issues with phones not receiving calls or making calls… as well as call quality issues. Rebooting the phones solves the problems. The OpenVPN logs contain a number of TLS Errors (TLS keys are out of sync)… as well as Auth/Decript errors (packet HMAC authentication failed). Logs are below. Think you forgot the logs. That should be enough of a summary to have a good idea though. What's the firewall/router/NAT device on the network where the 3 phones reside? That sounds like what could happen with a NAT device that doesn't handle UDP well. Some consumer-grade routers and some NAT implementations built into DSL/cable modems can have problems handling long-lived UDP connections especially where multiple devices are being NATed out to a single destination IP and port. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
On Tue, Feb 17, 2015 at 11:13 PM, Chuck Mariotti cmario...@xunity.com wrote: Think you forgot the logs. That should be enough of a summary to have a good idea though. What's the firewall/router/NAT device on the network where the 3 phones reside? That sounds like what could happen with a NAT device that doesn't handle UDP well. Some consumer-grade routers and some NAT implementations built into DSL/cable modems can have problems handling long-lived UDP connections especially where multiple devices are being NATed out to a single destination IP and port. And here is the log below... argh. The devices are behind a 256Mbit cable modem... Any suggestions on how to resolve if that is the case? 3rd party router? Feb 17 22:35:49 openvpn[78847]: Phone-Ext213/172.172.172.66:1086 send_push_reply(): safe_cap=940 Feb 17 22:35:47 openvpn[78847]: MULTI_sva: pool returned IPv4=10.9.12.14, IPv6=(Not enabled) Feb 17 22:35:47 openvpn[78847]: 172.172.172.66:1086 [Phone-Ext213] Peer Connection Initiated with [AF_INET]172.172.172.66:1086 Feb 17 19:50:44 openvpn[78847]: Phone-Ext212/172.172.172.66:1194 send_push_reply(): safe_cap=940 Feb 17 19:50:42 openvpn[78847]: Phone-Ext212/172.172.172.66:1194 MULTI_sva: pool returned IPv4=10.9.12.18, IPv6=(Not enabled) Feb 17 19:50:42 openvpn[78847]: 172.172.172.66:1194 [Phone-Ext212] Peer Connection Initiated with [AF_INET]172.172.172.66:1194 Feb 17 19:49:39 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [0] Feb 17 19:49:37 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 TLS Auth Error: TLS object CN attempted to change from 'Phone-Ext212' to 'Phone-Ext211' -- tunnel disabled Feb 17 19:49:37 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Auth Error: TLS object CN attempted to change from 'Phone-Ext211' to 'Phone-Ext212' -- tunnel disabled That's definitely the cable modem's NAT getting confused. If you can get the phones to randomize their source ports on their OpenVPN traffic, that might resolve. I'm not sure if that's possible on those phones. In stock OpenVPN, specifying lport 0 in the config will make it choose a random port. I'm not sure if that's configurable for the Yealink phones though. We disable that automatically in our OpenVPN client export for Yealink because they didn't support it at least up until recently. If you can change the modem to bridge mode to pass through the public IP to a router of some sort that will properly handle that circumstance, it'll resolve that. That might be hit or miss with consumer-grade routers. A completely default pfSense config will work fine in that circumstance, as it'll randomize the source ports on its own so the phones don't have to. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
Think you forgot the logs. That should be enough of a summary to have a good idea though. What's the firewall/router/NAT device on the network where the 3 phones reside? That sounds like what could happen with a NAT device that doesn't handle UDP well. Some consumer-grade routers and some NAT implementations built into DSL/cable modems can have problems handling long-lived UDP connections especially where multiple devices are being NATed out to a single destination IP and port. And here is the log below... argh. The devices are behind a 256Mbit cable modem... Any suggestions on how to resolve if that is the case? 3rd party router? Feb 17 22:35:49 openvpn[78847]: Phone-Ext213/172.172.172.66:1086 send_push_reply(): safe_cap=940 Feb 17 22:35:47 openvpn[78847]: MULTI_sva: pool returned IPv4=10.9.12.14, IPv6=(Not enabled) Feb 17 22:35:47 openvpn[78847]: 172.172.172.66:1086 [Phone-Ext213] Peer Connection Initiated with [AF_INET]172.172.172.66:1086 Feb 17 19:50:44 openvpn[78847]: Phone-Ext212/172.172.172.66:1194 send_push_reply(): safe_cap=940 Feb 17 19:50:42 openvpn[78847]: Phone-Ext212/172.172.172.66:1194 MULTI_sva: pool returned IPv4=10.9.12.18, IPv6=(Not enabled) Feb 17 19:50:42 openvpn[78847]: 172.172.172.66:1194 [Phone-Ext212] Peer Connection Initiated with [AF_INET]172.172.172.66:1194 Feb 17 19:49:39 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [0] Feb 17 19:49:37 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 TLS Auth Error: TLS object CN attempted to change from 'Phone-Ext212' to 'Phone-Ext211' -- tunnel disabled Feb 17 19:49:37 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Auth Error: TLS object CN attempted to change from 'Phone-Ext211' to 'Phone-Ext212' -- tunnel disabled Feb 17 19:49:31 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:49:27 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:49:25 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:49:20 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:49:18 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:49:18 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:49:18 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:49:15 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:49:09 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:49:05 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:49:05 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:49:01 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:48:57 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:48:55 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:48:50 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:48:48 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:48:48 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:48:48 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 19:48:45 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:48:44 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 17 19:48:39 openvpn[78847]: Phone-Ext211/172.172.172.66:1194 TLS Error: local/remote TLS keys are out of sync: [AF_INET]172.172.172.66:1194 [3] Feb 17 16:35:45 openvpn[78847]: Phone-Ext212/172.172.172.66:1086 send_push_reply(): safe_cap=940 Feb 17 16:35:42 openvpn[78847]: MULTI_sva: pool returned IPv4=10.9.12.18, IPv6=(Not enabled) Feb 17
Re: [pfSense] OpenVPN (pfSense 2.1.5-RELEASE) - VoIP Phone Issues
That's definitely the cable modem's NAT getting confused. If you can get the phones to randomize their source ports on their OpenVPN traffic, that might resolve. I'm not sure if that's possible on those phones. In stock OpenVPN, specifying lport 0 in the config will make it choose a random port. I'm not sure if that's configurable for the Yealink phones though. We disable that automatically in our OpenVPN client export for Yealink because they didn't support it at least up until recently. If you can change the modem to bridge mode to pass through the public IP to a router of some sort that will properly handle that circumstance, it'll resolve that. That might be hit or miss with consumer-grade routers. A completely default pfSense config will work fine in that circumstance, as it'll randomize the source ports on its own so the phones don't have to. Thanks Chris, I've emailed Yealink support but it seems they are off until mid-next week (Chinese New Year). Not sure what to do, purchase a 3rd party router to see if solves the problem or if I should wait to see what Yealink's answer is first. Reading up on the modem seems like bridge mode is a little problematic... maybe a call to the cable provider first to see options. Thanks Again, Chuck ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
