Alexa cards and images from my backend service through caddy proxy

[Benjamin_Anderson]

This is very strange.

I have an Alexa custom skill which controls a back in service (emby media server)

I proxy emby through caddy, which is set up though a domain and uses https.

From what I gather, information travels back and forth through caddy’s websocket to embys websockets, to my custom skill.

It works wonderfully for json information. Full control of emby, and string data moves freely between the services.

One of the options for Alexa custom skills is the ability to create card data which gets sent to your various echo screen devices in your home.

Again, the string information works flawless, but image data does something different.

When Alexa contacts my domain for information and it gets routed through caddy, the only way to attach an image to the card is to use the subnet address (example 192.168.2.126). This is the only way the image seems to be available.

This causes an issue because amazon wants a TLS enabled endpoint for image aquisition, and my subnet address isn’t https.

It just won’t work through the proxy set up in caddy, so long as the devices are in the same subnet as the server hosting the service.

What is the issue? Is there a name for this type of behaviour in servers?

It is like trying to contact your domain from inside the host network… That won’t work. It seems like the same thing is happening here.

It’s hard to Google possible fixes because I’m not exactly sure what the problem is called… Because I’m so new to this sort of thing.

Any possible information which would help my learning curve would be much appreciated.

Thank you in advance.

[Whitestrake (Matthew Fay)]

Hi @Benjamin_Anderson - just a few questions to clarify some points:

@Benjamin_Anderson

When Alexa contacts my domain for information and it gets routed through caddy, the only way to attach an image to the card is to use the subnet address (example 192.168.2.126).

When you refer to Alexa here, are you referring to Amazon’s servers, or are you referring to your own Alexa device? Is your Alexa device on the same network as your server?

By “subnet address”, I am assuming you mean private IP address (i.e. in your LAN)?

What actually happens when you don’t “use the subnet address”? What is the alternative (do you instead use your domain)? What behaviour are you observing when the alternative isn’t functioning?

@Benjamin_Anderson

It is like trying to contact your domain from inside the host network… That won’t work. It seems like the same thing is happening here.

You can actually configure this to work with NAT loopback or split DNS. Having this would have been my initial hunch too, but there’s one problem - you say you have application/json data transported just fine.

For images to fail and json to work, the images would have to be a direct Alexa device → server connection while the json would have to be retrieved by Amazon itself and forwarded to your device.

@Benjamin_Anderson

It’s hard to Google possible fixes because I’m not exactly sure what the problem is called… Because I’m so new to this sort of thing.

I don’t think this problem has a specific name, per se. It’s just a side effect of how NAT and port forwarding works.

When you set up a port forward, you are telling your router: “When a packet hits the WAN interface on port X, take that packet and send it out on the LAN interface, addressed to IP address Y.”

However, when a device inside the LAN tries to access the public IP address, those packets don’t actually hit the WAN interface, they hit the LAN interface. They’re coming from the wrong direction. Thus, no firewall processing, and no port forwarding.

NAT loopback (aka hairpinning, aka reflection) is a setting you can enable on most routers that effectively tells it, “when a packet hits the LAN interface, but it’s addressed to the WAN IP, pretend it actually came in on the WAN interface for firewall / port forwarding purposes.” Some say this is a lazy solution because you’re having the router double handle all of those packets.

Split DNS just involves having a DNS resolver inside your LAN that returns the LAN IP for requests to the domain hosted on that network instead of the WAN IP, so that requests inside the LAN go straight to the server instead of going to the router and back. This, however, means you need a way to maintain which domain names should resolve to which local IP addresses.

Like I said, though, if this problem were across the board - I’d have expected the json to also have issues. So unless json and the images are handled very differently by Alexa, it’s probably not the root problem.