title: Why would IP masquerading fix problematic WebRTC connection?
body: <p>I'm working with a WebRTC stack that consists of a (firewall-enabled) embedded Linux device, an iOS mobile app, and self-maintained signaling, STUN, and TURN servers.</p>
  
  <p>In 99% of network configurations, the setup works just fine. However, when the embedded Linux device is connected to a <a href="https://www.verizonwireless.com/support/jetpack-4g-lte-mobile-hotspot-mifi-4620l/" rel="nofollow noreferrer">Verizon Jetpack</a> (4G LTE), the device cannot establish a WebRTC connection with the mobile app (regardless of whether the mobile phone is connected to the Jetpack or some other network). </p>
  
  <p>In an effort to debug, I took down the entire firewall on both IPv4 and IPv6, but it made no difference.</p>
  
  <p>Then, I kind of randomly discovered that if I add a masquerading post-routing IPv4 rule to the device's NAT table, it starts working! Specifically, this is the <code>iptables</code> command that I used:</p>
  
  <pre><code>$ sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
  </code></pre>
  
  <p>Why would this rule get the WebRTC connection working? And is there a more proper way to achieve the same result? The rule above seems too liberal.</p>