This has been an ongoing issue for a couple of weeks. The credit card terminal will lose the ability to connect to the processor server over SSL.
The IP config looks correct, the DHCP lease looks legit and it appears to
have connectivity to the Internet,
but transactions will not complete.For a time we suspected a hardware failure, but the new terminal was fine for 3-4 days and then failed yesterday the same as the prior terminal.
I can netcat right into the processor host plugged into the same Cisco 2950 as the card terminal.
When the transaction is attempted I can see:
Ethernet Session Error
and then:
Invalid address
In the error log I see that the Debug Buffer states
VfyCertChain: NOT Verified! Reason 2 (CERT_SIGNATURE_FAILURE) VfyCertChain: NOT Verified! Reason 1 (UNABLE_TO_GET_ISSUER_CERT) VerifyDataBundle ERROR 112 Bus App Signer VerifyDDLSysSig: ERROR NOT TCMS Bundle
This was working yesterday, but today it does not work. This happened twice before in the past two weeks and never previously for 2+ years behind a lousy consumer router.
I don't see any blocked traffic in the pf logs that matches either the processor host IP or the terminal IP.
So it appears to be an issue with SSL Cert issuer verification but if I plug into my consumer router at home I have no issues completing transactions.
I can easily renew the IP address on the terminal and it always reports connectivity.
This particular model includes an IP Diagnostics utility which runs four tests:
- LAN Connection - Tests that Ethernet connection exists.
- Gateway Test - Tests that the GW is responsive(?)
- ISP Test - If there were a PPP connection directly involved, I might know what this tests exactly, as it stands no one can tell me what exactly is happening under the hood?
- Host Test - Tests that the connection to the processor server is successful(?)
I have restored the pfsense config to a previously known-good point but this did not clear the card terminal issue.
So my question is:
Does anyone have any experience resolving a similar situation?
Some other thoughts I had were that I was too hasty in configuring a local instance of BIND or that I have misconfigured pfsense (DHCP Server possibly). I am pretty new to pfsense and credit card terminals.
I am about to deploy another nameserver in this workgroup environment of ~16 total clients (mostly XP & Windows 7) in the hopes that I just got something wrong there.
I am pretty desperate for fresh insight into this issue. This should be a non-issue in 7-10 days when we go to a different processing system, but until then the retail area is without a card reader and that makes small business owners very sad.
: (
Please help.
I'll start off warning you that I have no experience with these devices at all. They're black boxes to me.
I'd start by sniffing the traffic between the device and the LAN on a "working" setup (the consumer router you talked about) and then again in the non-working setup.
Comparing the traffic logged should provide a lot of insight into what's going on. Presumably that device, being embedded, will act in a very similar manner each time it's powered-on and the differences between the two configurations ought to be at least somewhat apparent.
I had a similar experience with a CC terminal (not the same model) that would not work even tho DHCP seemed to be handing it a valid address. The key to fixing it for me (and maybe for you) was to give it a local static ip. Once I setup the ip manually I never had another problem with it. The next terminal we got had the same problem until I gave it a static ip address so it seemed to be with all of the units and not just with one of them.
For what it's worth I believe they were Verifone Omni terminals and they were connecting to a Juniper Netscreen Router. DHCP & DNS was provided by a windows server 2003 box.
Anyway I'd give a local static ip a shot and see what happens.