Having been deemed the “AS2 Queen” in EDI circles, I thought it would be nice to summarize five of the most common mistakes that I have encountered in working with AS2 connections and support. The AS2 communication protocol for EDI can be a very cost-efficient solution for companies wanting to exchange documents directly with their EDI trading partners to encrypt and secure their EDI data. This protocol can also be used to connect to VANs as well. It can be tricky though to set up especially when it is your first time doing an AS2 connection with a trading partner or VAN. Once the setup has been completed and your firewall supports it, it does get a bit easier each time you set up another AS2 connection.
The five most common mistakes that I have seen in AS2 configurations are as follows:
1) Ports are incorrect
For AS2 inbound communications, make sure your AS2 trading partner is using the correct port that you are expecting them to communicate to you with. This port should have been configured to listen for AS2 traffic from within your AS2 application. The port is referenced in your AS2 URL that you have provided to them.
For AS2 outbound communications, ensure your AS2 application server can communicate using your AS2 trading partner’s designated AS2 port when sending data to your trading partner. Your AS2 trading partner will provide you with the correct port to use when communicating with them as part of their AS2 URL.
2) Not all firewall rules are in place to support AS2 communications
For AS2 Inbound communications to be successful, your firewall must allow for AS2 communications via an AS2 specified port. This port must be open on your firewall. This can be done one of two ways. Your firewall may be locked down and only allow certain IP addresses to communicate through the AS2 designated port. It is important to obtain a list of sending IP addresses from your AS2 trading partners and limit permissions on your AS2 port to only those sending IP addresses that you authorize to lower your vulnerability. This is the preferred method. However, I have also seen firewalls that have been configured to allow for all traffic to come through on an AS2 designated port although I do not recommend this.
For AS2 Outbound communications to be successful, ensure your firewall allows for your AS2 application to send out via your trading partner’s AS2 port. This will be the port they expect you to be sending data to them on. In most companies, all outgoing internet traffic is allowed when it is initiated from within their own firewall. Some companies will go so far as to lock down their firewall to only allow their AS2 applications to send using the specific ports that were requested by their AS2 Trading Partners.
Keep in mind that your trading partner’s firewall may also have to be considered for both AS2 inbound and AS2 outbound communications. They may have to open your AS2 designated port to be able to communicate to you for AS2 inbound communications to work. Also, they may have their AS2 designated port restricted to only allow certain EDI trading partner sending IP addresses as well. They may need to add your sending IP addresses to their firewall. Make sure you ask the question up front to find out if they need your sending IP addresses for their firewall updates. You may find that you may have additional firewall rules that change the IP address going out so you must obtain the correct sending IP addresses from your network administrator. Many times there are internal NAT translations and port forwarding rules that take place that we are not aware of as they happen behind the scenes.
3) Incorrect AS2 URL references
For AS2 Inbound, make sure that you have provided the correct AS2 URL to your AS2 trading partners. It may be in the format of the following: http://edi.abccompany.com:7070/abccompanyas2id where edi.abccompany.com may be your DNS name that resolves back to an external IP address that is rerouted to your AS2 application, port 7070 is your AS2 designated port, and abcompanyAS2ID or your trading partner’s AS2ID may be the virtual folder for them to communicate data to.
For AS2 Outbound, make sure you are using the correct AS2 URL to send out. Your AS2 trading partner will provide this to you.
For https vs. http, there may be additional configuration requirements as well within your AS2 application and on your AS2 trading partner’s configuration as well.
4) Incorrect AS2 IDs being utilized
It is important to ensure that within your configuration that you are utilizing the correct AS2 sender ID and AS2 receiver ID for each AS2 connection. The AS2 IDs are case sensitive and both parties’ AS2 IDs must exactly match for the connection to take place.
5) Incorrect Digital Certificates being referenced
Ensure that you are referencing the correct certificates for signing and encrypting when setting up your AS2 Inbound and AS2 Outbound configurations. If any of the certificate serial numbers are not the same on both sides, the connection will be refused.
As you can see these five mistakes can be costly mistakes in trying to successfully test new AS2 connections with your trading partners or VANS. Between ports, firewall rules, AS2 URLs, AS2 IDs, and AS2 Digital certificates, you can spend quite a bit of time trying to diagnose where the problem lies as there can be issues on both sides of the communications. I hope that this article may help in diagnosing where your issues lie and reduce your diagnostic time to achieve a successful AS2 connection.
If you’re looking for proven AS2 software, along with skilled professionals to support it, ask us for a free consultation.
