Warning: networking jargon ahead. So, this has baffled the bajeezus out of me. I have a device that essentially runs my cellphone service through my internet connection as I live in an area with poor reception. This device works by establishing an IPsec VPN tunnel to the cell provider's servers, and talking to them through it. This is accomplished on port 4500. I'm routing my entire network's traffic through an openvpn connection (the issue occurs both on, and off the VPN), so just think of the VPN as a good ole fashioned WAN gateway. The device is set on a static DHCP lease at 10.0.0.21, the other LAN address (10.0.0.206) is a phone using similar technology except in a wifi-calling configuration. For some reason, I cannot for the life of me get this box to talk on 4500. I've gone so far as to set it as the DMZ to no avail. What's more interesting is that the device on 10.0.0.206 has no trouble talking on that port. I'm open to any and all suggestions. Maybe one of you folks will have the solution. I raise a reward to the one who can help me solve this puzzle, an image of a cookie, because if I made you real cookies you'd probably barf because you'd be eating charcoal. I'll be happy to chat in discord or teamspeak and screenshare. Send me a forum PM if you're interested in getting a headache for free. By the way, I've already tried turning it off and back on again, deleting system32, installing gentoo, rm -rf, and alt+f4.
"ipsec passthrough" is a PITA on a good day, have you tried a large(r) hammer? Some more information about the tcp/udp states Code: udp.single The state if the source host sends more than one packet but the destination host has never sent one back. udp.multiple The state if both hosts have sent packets. *.206 has traffic flowing both ways, *.21 only has traffic from the client, not receiving any. That indicates that the destination (*.*.209.6) is not accepting connections on port 4500. Easiest way to verify that the problem isn't your firewall/connection is if you try connectint to the destination from a shell on the pfSense box. If you use ssh or a real keyboard to access pfsense doesn't matter. Code: telnet *.*.209.6 4500 A time-out or connection refuse is a clear sign that you should give the phone/vpn provider support a call. Note that by telnetting from the pfsense box and not a client behind it, you can be certain that the firewall isn't causing it. Edit: You should replace the "8.8.8.8" in the above screenshot with the IP that got the state "SINGLE:NO_TRAFFIC". Most stuff you read about ipsec that involves port 50/51/500 and/or GRE can you ignore, that's devices that doesn't support NAT traversal (Port 4500).
I've been tinkering with it some more, and I think I might have found something, but I'm not sure at this point. Ran tcpdump on all incoming and outgoing connections on 4500 on the WAN side of my network, and I've gotten this: On the LAN Side (Monitoring specific IP having trouble) Perhaps you or someone could make sense of this better than I can. I'm seeing length mismatch and I'm really tempted to play with MTU/MSS.
