API Call Failure Caused by Watchguard??

RadFi

Im unable to send API call out from machine behind the Firebox T20. Traffic monitor shows ALLOW outbound of DNS lookup for the call as well as an ALLOW to the call itself. Wireshark shows DNS calls resolving and call out and ACK respond then a Retransmission. Script still crashes at the api call. I am able to use same source code from another of our forward facing servers and everything works as expected. I guess i am asking is the WG setup by default to allow 443 out and back into the machine that called?

james.carson

@RadFi
If you're getting an ACK from that service, the firewall likely isn't doing anything and your problem lies elsewhere. I'd suggest checking on the server that you're trying to connect to for any errors.

james.carson

@RadFi
By default the "outgoing" policy will allow this. If an HTTPS proxy it in use, it may be trying to inspect or do something else to your traffic.

Try making an https packet filter from your PC that you're testing from, to the FQDN or IP you're sending the request to, and ensure that policy is above any https proxies. That can troubleshoot if it is the proxy causing the problem or not.

RadFi

Hey @james.carson thank you for the response. Would the default "outgoing" policy be used if the script is specifying HTTPS:// ? I see the allow in the traffic monitor when the script calls the api and it shows using the HTTPS-Proxy-00 policy. I thought maybe because the policy was only using Any-Trusted as the "From" that it was not allowing the return to come back. So i created a new Https-Policy.1 to allow "From" Any-External (for now) to a static nat of INTO public ip address of the firebox to the static ip of the box running the script. I dont know if this is correct but i am getting desperate. Where do i create a https packet filter? And this filter should use the FQDN of the rest api thats being called, and just allow this in?

I apologize for my ignorance i struggle with networking. It took me 6 days to get an IPSEC IKEv2 tunnel up and working with the T20 and a Cisco 1921.

james.carson

It'll use whatever policy it matches first -- if there's an HTTPs proxy above the outgoing rule, it'll probably hit that.

You can create a packet filter by going to

Policy manager: edit -> add policy. Expand the packet filter folder, and find https, then click add policy.

WebUI: Go to Firewall -> Firewall Policies. Click Add policy. Click the radio button for packet filter, and find HTTPS in the list. Click add policy.

You can use FQDN or IP in your rules -- if you're using FQDN, ensure that the firewall is resolving the address to the one you think it is (for example, if your client is using an internal DNS server, but the firewall is looking at google's 8.8.8.8 you may get different responses.)

RadFi

Ok i created this new HTTPS policy as described. I turned logging on to show in the traffic monitor. The traffic monitor shows the allow out using the newly created policy. Still not getting through to the API though.

james.carson

Hi @RadFi
If we're seeing an allow log via a packet filter, that means the full TCP handshake is happening (therefore the server is responding somewhat.)

Via a packet filter, the firewall isn't doing anything but inspecting that the port, source IP, and Destination IP match the policy.

-Do you see any logs on the service you're trying to connect to stating what the problem might be?
-If you run a packet capture for that traffic, do you see the server responding?

(You can run a packet capture via Firebox System Manager, under Tools -> diagnostic tasks.)
-Go to Tools -> Diagnostic Tasks.
-Select TCP DUMP from the drop down menu.
-Select the advanced options checkbox.
-In the arguments field, type in "-i eth0 host 52.63.203.152 and port 443"
(change eth0 to whatever port your external interface is if it isn't port 0.)
-Click Run task, and try running your query. If the server is responding you should see lines with its IP first followed by yours.

RadFi

I dont see anything on the service. I have a wireshark packet capture, i have done about 25 of them, all of them do show a response ACK from the service IP.

Dont worry about 192.168.1.2 It is accross my VPN tunnel and sending to 10.0.1.25
Box sending to API 10.0.1.25
ISP DNS server 71.10.216.X

RadFi

I will do a packet capture through the watchguard and post.

RadFi

I have requested they check the logs for me. I do not think it is this one API considering i get the same behavior from any i try so far.

RadFi

Question if your still around. If i am running IIS on the machine behind the WG, and the machine has the WG cert installed in its local store. Should i be able to call a script through the web browser on that machine and successfully send/receive from a secure API?

_WGSupport_ChrisC

If the API traffic is going through a packet filter, it should be no problem. There is a very slim chance a subscription service is interfering, but extremely unlikely if the traffic is all TLS encrypted. If using HTTPS proxy, could be a problem regardless if the certificate for content inspection is installed. I've seen this happen more than a few times. It's designed for web browsing, and REST API traffic has similarities. Bypassing it either for the device sending or receiving API traffic can be done with a packet filter place higher up, which could match on the host's internal IP, or the IP or FQDN of any remote hosts.

RadFi

Thank you Chris. Im sorry i should have reported back sooner. After all the testing done from this forum it all lead us to believe it was not in the WatchGuard and it turned out it was not. We actually found a bug in the programming language having to do with a newer version of openssl. The WG was doing its job properly and the script was failing but never exiting or throwing an exception. Since downgrading we have been able to get around this. Thanks again for all the help.