HOWTO
Introduction
OpenVPN is a full-featured SSL VPN which implements OSI layer 2 or 3 secure network extension using the industry standard SSL/TLS protocol, supports flexible client authentication methods based on certificates, smart cards, and/or username/password credentials, and allows user or group-specific access control policies using firewall rules applied to the VPN virtual interface. OpenVPN is not a web application proxy and does not operate through a web browser.
OpenVPN 2.0 expands on the capabilities of OpenVPN 1.x by offering a scalable client/server mode, allowing multiple clients to connect to a single OpenVPN server process over a single TCP or UDP port.http://www.blogger.com/img/blank.gif
This document provides step-by-step instructions for configuring an OpenVPN 2.0 client/server VPN, including:
OpenVPN Quickstart.
Installing OpenVPN.
Determining whether to use a routed or bridged VPN.
Numbering private subnets.
Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients.
Creating configuration files for server and client
Starting up the VPN and testing for initial connectivity.
Configuring OpenVPN to run automatically on system startup.
Controlling a running OpenVPN process.
Expanding the scope of the VPN to include additional machines on either the client or server subnet.
Pushing DHCP options to clients.
Confihguring client-specific rules and access policies.
Using alternative authentication methods.
How to add dual-factor authentication to an OpenVPN configuration using client-side smart cards.
Routing all client traffic (including web-traffic) through the VPN.
Running an OpenVPN server on a dynamic IP address.
Connecting to an OpenVPN server via an HTTP proxy.
Connecting to a Samba share over OpenVPN.
Implementing a load-balancing/failover configuration.
Hardening OpenVPN Security.
Revoking Certificates.
Additional Security Notes.
The impatient may wish to jump straight to the sample configuration files:
Server configuration file.
Client configuration file.
Intended Audience
This HOWTO assumes that readers possess a prior understanding of basic networking concepts such as IP addresses, DNS names, netmasks, subnets, IP routing, routers, network interfaces, LANs, gateways, and firewall rules.
If you don't have a handle on these basics, but would still like to set up OpenVPN, I would encourage you to hire an OpenVPN expert on a consulting basis. Many of the authors on the articles page are available for consulting, or you can contact the creators of OpenVPN at info@openvpn.net.
Additional Documentation
http://www.packtpub.com/openvpn/book/mid/2405065clw5q
OpenVPN Books
OpenVPN Book
OpenVPN: Building and Integrating Virtual Private Networks
by Markus Feilner
Packt Publishing Ltd
ISBN 190481185X
[Reviews]
OpenVPN 1.x HOWTO
The original OpenVPN 1.x HOWTO is still available, and remains relevant for point-to-point or static-key configurations.
OpenVPN Articles
For additional documentation, see the articles page.
Sunday, April 15, 2012
Tuesday, April 10, 2012
AS 400
I am new to VoIP, I've just deployed ASG400 and suceeded in configuring for outgoing calls, but I am still unable to configure it for incoming calls i-e couldn't make calls land on it.
I'll be very gratefull if one helps me figuring out.
There is a asociation that you need to make on the PSTN side.
On the GUI go under "circuit configuration","trunk routing configuration",and create a "hopoff number directory"
You need to enter the prefix of the calls that you wanted to send to the PSTN side.
Like if you are in Argentina, Buenos aires, you will enter country code 54, area code 1.
The entry will look like "541*", meaning that any call coming VOIP that have the number 541 followed ny any digits will be sent to the PSTN port of the Quintum.
IF you need to send any aditional digits, like a "9" to access a outside line from the Quintum, enter that didigt or digits on the "replcement number" field of the hopoff directory.
If you still confuse after that, try the following command:
quintum# cmd gkroute xxxx the "xxx" will be the three or four first digits of the call that you want to send to the PSTN
Quintum# cmd gkroute 1281 or 541, or 44.
If everything is setup correctly, you will get a reply that incluides the I.P. of your own gateway.
Best luck!!!!
I'll be very gratefull if one helps me figuring out.
There is a asociation that you need to make on the PSTN side.
On the GUI go under "circuit configuration","trunk routing configuration",and create a "hopoff number directory"
You need to enter the prefix of the calls that you wanted to send to the PSTN side.
Like if you are in Argentina, Buenos aires, you will enter country code 54, area code 1.
The entry will look like "541*", meaning that any call coming VOIP that have the number 541 followed ny any digits will be sent to the PSTN port of the Quintum.
IF you need to send any aditional digits, like a "9" to access a outside line from the Quintum, enter that didigt or digits on the "replcement number" field of the hopoff directory.
If you still confuse after that, try the following command:
quintum# cmd gkroute xxxx the "xxx" will be the three or four first digits of the call that you want to send to the PSTN
Quintum# cmd gkroute 1281 or 541, or 44.
If everything is setup correctly, you will get a reply that incluides the I.P. of your own gateway.
Best luck!!!!
H.323 and SIP
I have written protocol stacks for both H.323 and SIP, and these power switches providing basic VoIP telephony services.
My opinion is that H.323 is the superior protocol for basic telephony, although for more advanced features such as conferencing, SIP may be more appropriate.
H.323 is less open to misinterpretation, because it is defined using ASN.1 syntax. Encoding is using PER, which is hard work for an implementer, but worth the effort. SIP is text based, and very easy to make a mistake with.
H.323 call signalling is based on Q.931, which is a telecoms industry standard. This makes it easier to map messages to TDM based telecommunications links.
H.323 is TCP based. TCP is a connection orientated protocol, and provides a mechanism for retransmissions and error checking. SIP is usually UDP based, so retransmission is built into the protocol itself, which adds another overhead for the developer.
H.323 is mature and supported (almost required) by high end equipment. For example, although Quintum have included UA functionality in the gateways and switches, for any serious application, H.323 is required.
Perhaps this is a little unfair, but SIP seems to be a hobbyist's protocol. I own and manage an ITSP (DUAL Talk). All of the serious business comes into my H.323 switch. Customers usihttp://www.blogger.com/img/blank.gifng SIP tend to have downloaded free copies of SER or Asterisk and originate very little traffic.
Having said these things, H.323 is not perfect. The Fast Start procedure for media negotiation is clumsy and there have been some backward compatibility issues in the past with H.323. Also, SoHo routers seem to handle SIP better than H.323.
It seems that SIP is gaining popularity for consumer applications and IP-PBX applications, whereas H.323 is holding on to the ground it has already gained in the business of switching revenue generating traffic.
But, at the end of the day, they are both only protocols that facilitate higher level applications, and they both do this well.
My opinion is that H.323 is the superior protocol for basic telephony, although for more advanced features such as conferencing, SIP may be more appropriate.
H.323 is less open to misinterpretation, because it is defined using ASN.1 syntax. Encoding is using PER, which is hard work for an implementer, but worth the effort. SIP is text based, and very easy to make a mistake with.
H.323 call signalling is based on Q.931, which is a telecoms industry standard. This makes it easier to map messages to TDM based telecommunications links.
H.323 is TCP based. TCP is a connection orientated protocol, and provides a mechanism for retransmissions and error checking. SIP is usually UDP based, so retransmission is built into the protocol itself, which adds another overhead for the developer.
H.323 is mature and supported (almost required) by high end equipment. For example, although Quintum have included UA functionality in the gateways and switches, for any serious application, H.323 is required.
Perhaps this is a little unfair, but SIP seems to be a hobbyist's protocol. I own and manage an ITSP (DUAL Talk). All of the serious business comes into my H.323 switch. Customers usihttp://www.blogger.com/img/blank.gifng SIP tend to have downloaded free copies of SER or Asterisk and originate very little traffic.
Having said these things, H.323 is not perfect. The Fast Start procedure for media negotiation is clumsy and there have been some backward compatibility issues in the past with H.323. Also, SoHo routers seem to handle SIP better than H.323.
It seems that SIP is gaining popularity for consumer applications and IP-PBX applications, whereas H.323 is holding on to the ground it has already gained in the business of switching revenue generating traffic.
But, at the end of the day, they are both only protocols that facilitate higher level applications, and they both do this well.
Subscribe to:
Posts (Atom)