[opensuse] How to setup SuSEfirewall2 to work with openVPN in openSUSE13.2
I'm running a openVPN server on openSUSE 13.2, a VPS server. However, I have problems to setup SuSEfirewall2 to work with openVPN, could anyone give me some suggesitons or guidence, thanks.:-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 01:09 AM, WangJihao wrote:
I'm running a openVPN server on openSUSE 13.2, a VPS server. However, I have problems to setup SuSEfirewall2 to work with openVPN, could anyone give me some suggesitons or guidence, thanks.:-)
It's been a while since I've used OpenVPN, but you just have to open the appropriate port. The default is UDP port 1194, but you can also use TCP 443 if absolutely necessary. You should only be using TCP if you have to use the VPN from a location where UDP is blocked. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 01:21 PM, James Knott wrote:
On 09/06/2015 01:09 AM, WangJihao wrote:
I'm running a openVPN server on openSUSE 13.2, a VPS server. However, I have problems to setup SuSEfirewall2 to work with openVPN, could anyone give me some suggesitons or guidence, thanks.:-)
It's been a while since I've used OpenVPN, but you just have to open the appropriate port. The default is UDP port 1194, but you can also use TCP 443 if absolutely necessary. You should only be using TCP if you have to use the VPN from a location where UDP is blocked.
TCP is also the option if you need to SSH tunnel, as you cannot (apparently.....) forward UDP ports. Also, just as something unrelated perhaps: you cannot forward localhost:1194 to some other localhost:1194 as a VPN client because NetworkManager will try to open 1194 for its own "management console". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 07:24 AM, Xen wrote:
TCP is also the option if you need to SSH tunnel, as you cannot (apparently.....) forward UDP ports.
Whenever possible, TCP should be avoided for a VPN. This is due to the flow control that's built into TCP. If you have a TCP VPN and run some TCP app over it, you may have performance issues, with 2 TCP sessions trying to control the same data stream. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 01:29 PM, James Knott wrote:
On 09/06/2015 07:24 AM, Xen wrote:
TCP is also the option if you need to SSH tunnel, as you cannot (apparently.....) forward UDP ports.
Whenever possible, TCP should be avoided for a VPN. This is due to the flow control that's built into TCP. If you have a TCP VPN and run some TCP app over it, you may have performance issues, with 2 TCP sessions trying to control the same data stream.
How about running a TCP app over a TCP VPN over a TCP tunnel :P. However I think the TCP issues are exaggerated here because one of these links (or even two) happen between two single hosts and I think it all works out well. I do experience a lot of downtime in my internet connection. I cannot really pinpoint it to either the router, the VPN server, or the local wifi hotspot. Sometimes my internet will be down but I can SSH into the VPN server no issue. Sometimes when I close my VPN my internet is full back right again. I get the maximum download speed that my VPN can achieve though, which is a result of my ISPs upstream limit. I was more worried about the double encryption. Not that it really mattered (thus far) but the encryption takes about 20% of my VPN server's CPU time (which is a small unit). If I turn VPN encryption off, it goes down to about 25% or 20% for a full-bandwidth data stream. It's unfortunate that KDE 4 from 13.2 doesn't support no-encryption with its network-manager-applet, but a workaround was not hard to reach. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 09:37 AM, Xen wrote:
However I think the TCP issues are exaggerated here because one of these links (or even two) happen between two single hosts and I think it all works out well.
There is normally only one flow control on a TCP connection, as it works end to end. With a TCP tunnel or VPN you add a 2nd. UDP has the same characteristics as Ethernet, that is best effort, no guarantees.
I do experience a lot of downtime in my internet connection. I cannot really pinpoint it to either the router, the VPN server, or the local wifi hotspot. Sometimes my internet will be down but I can SSH into the VPN server no issue. Sometimes when I close my VPN my internet is full back right again. I get the maximum download speed that my VPN can achieve though, which is a result of my ISPs upstream limit.
I was more worried about the double encryption. Not that it really mattered (thus far) but the encryption takes about 20% of my VPN server's CPU time (which is a small unit). If I turn VPN encryption off, it goes down to about 25% or 20% for a full-bandwidth data stream.
Other than a waste of CPU, I don't know that multiple encryption is a problem. On the other hand, it might be providing more work for the NSA. ;-) As I mentioned earlier, I no longer use OpenVPN. I now have IPv6, so all my computers have a public address and I use encrypted protocols such as SSH and IMAPS to access my network. So, my firewall is configured to pass only those.
It's unfortunate that KDE 4 from 13.2 doesn't support no-encryption with its network-manager-applet, but a workaround was not hard to reach.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 11:28 AM, James Knott wrote:
There is normally only one flow control on a TCP connection, as it works end to end. With a TCP tunnel or VPN you add a 2nd. UDP has the same characteristics as Ethernet, that is best effort, no guarantees.
One other thing, UDP protocols such as SIP can really get messed up by passing through a TCP tunnel. The TCP flow control interferes with the timing necessary for voice calls. There is normally an adaptive buffer that handles the jitter in a series of UDP packets. With TCP flow control and guaranteed delivery, you can easily exceed that buffer. Then the buffer time will increase, causing excessive delay etc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On September 6, 2015 10:55:06 AM PDT, James Knott
On 09/06/2015 11:28 AM, James Knott wrote:
There is normally only one flow control on a TCP connection, as it works end to end. With a TCP tunnel or VPN you add a 2nd. UDP has the same characteristics as Ethernet, that is best effort, no guarantees.
One other thing, UDP protocols such as SIP can really get messed up by passing through a TCP tunnel. The TCP flow control interferes with the timing necessary for voice calls. There is normally an adaptive buffer that handles the jitter in a series of UDP packets. With TCP flow control and guaranteed delivery, you can easily exceed that buffer. Then the buffer time will increase, causing excessive delay etc.
Not sure I believe that. Most sip clients and servers off tcp support these days, an in my experience the connection is clearly superior. Voice is not that demanding. Buffering issue haven't been an issue between my UK customers and our offices. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 02:10 PM, John Andersen wrote:
Voice is not that demanding. Buffering issue haven't been an issue between my UK customers and our offices.
That depends on whether it's interactive, such as a phone call, or not. With phone calls, delays of 400 mS or more can really interfere with speech. On the other hand, one way speech wouldn't be affected by several seconds of buffering. Years ago, when satellites were used for intercontinental phone calls, a call would go via the satellite in one direction and undersea cable in the other, in order to minimize delay. Of course, with VoIP and cell phones, there is already a built in delay and any due to buffering, latency, etc. simply adds to it. As for TCP, you can often have significant buffers, much larger than are typically used with SIP/RTP and if there's a lost packet, the flow to the receiver stops, until that missing block is replaced. With UDP, the missing data is simply ignored and there are some methods used to minimize the impact on call quality. Now, with TCP, the receiver typically sets the buffer or sliding window size, but the transmitter has to realize that some data is missing, which depends on flow control timers and then transmit again. How long will that take? Depending on the TCP implementation, that transmitter may retransmit all the data after the missing block too, which adds more delay for following data. I've experienced enough YouTube etc. videos that were starved to know you don't want that to happen in a phone call. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 11:32 AM, James Knott wrote:
On 09/06/2015 02:10 PM, John Andersen wrote:
Voice is not that demanding. Buffering issue haven't been an issue between my UK customers and our offices.
That depends on whether it's interactive, such as a phone call, or not. With phone calls, delays of 400 mS or more can really interfere with speech. On the other hand, one way speech wouldn't be affected by several seconds of buffering.
Years ago, when satellites were used for intercontinental phone calls, a call would go via the satellite in one direction and undersea cable in the other, in order to minimize delay. Of course, with VoIP and cell phones, there is already a built in delay and any due to buffering, latency, etc. simply adds to it.
As for TCP, you can often have significant buffers, much larger than are typically used with SIP/RTP and if there's a lost packet, the flow to the receiver stops, until that missing block is replaced. With UDP, the missing data is simply ignored and there are some methods used to minimize the impact on call quality. Now, with TCP, the receiver typically sets the buffer or sliding window size, but the transmitter has to realize that some data is missing, which depends on flow control timers and then transmit again. How long will that take? Depending on the TCP implementation, that transmitter may retransmit all the data after the missing block too, which adds more delay for following data. I've experienced enough YouTube etc. videos that were starved to know you don't want that to happen in a phone call.
Well, I know that TCP is offered as an option in many SIP clients, but I don't know exactly what it is used for. It might just be session initiation, and then UDP for voice, and maybe falling back to TCP for file transfers. TCP connections to the sip server can sit idle for looooong periods of time with no traffic at all (essentially until timeout occurs - around 18 minutes). This would drastically reduce the idle traffic needed for presence detection. It might be that actual sip calls do go to UDB. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 03:25 PM, John Andersen wrote:
Well, I know that TCP is offered as an option in many SIP clients, but I don't know exactly what it is used for. It might just be session initiation, and then UDP for voice, and maybe falling back to TCP for file transfers.
SIP, which is the control protocol typically used with RTP can run over UDP or TCP. It is just the control messages and buffer time is not an issue. In fact, SIP is similar to HTTP with plain text and acknowledgements. RTP is the protocol that actually carries the content. It is what's sensitive to delay and jitter.
TCP connections to the sip server can sit idle for looooong periods of time with no traffic at all (essentially until timeout occurs - around 18 minutes). This would drastically reduce the idle traffic needed for presence detection.
It might be that actual sip calls do go to UDB.
I've never heard of SIP calls (actually RTP) on TCP. It uses UDP. Here are a couple of links you may want to read: SIP - https://en.wikipedia.org/wiki/Session_Initiation_Protocol RTP - https://en.wikipedia.org/wiki/Real-time_Transport_Protocol BTW, I have set up VoIP over IPSec VPNs without problem. IPSec tunnels use a connectionless protocol similar to UDP. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2015 02:10 PM, John Andersen wrote:
Buffering issue haven't been an issue between my UK customers and our offices.
Are those calls via TCP or UDP? The tunnel? VPNs are normally UDP unless forced to use TCP by firewall. The only place I've tried to use a UDP tunnel that was blocked is the local library, where only HTTP(S) is allowed and even things like email fail. That some protocols can support TCP when necessary doesn't change the fact that they work better over UDP without TCP flow control messing things up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
James Knott -
John Andersen -
WangJihao -
Xen