Cisco BT Signal Booster behind pfSense
-
Hi all
New to the forum so apologies if I am asking something that is already answered - I have had a look through but as I don't necessarily know the right terminology for the issue i have I may have missed something. Thanks for any help in advance!
I have pfSense running on an old HP desktop which has a dual port Intel NIC and an onboard NIC. The intel NICs are connected as LAN and WAN and the onboard device is connected now to just a BT Cisco Signal Booster. The signal booster creates a VPN back to the mobile provider - well… it is supposed to. Unfortunately (after many tries) I have been unable to allow it to create the VPN. I believe it is failing because it does not have NAT-T enabled (that the box itself is freaking out because the packets it gets back are not what it expects?) - but I don't have any options i can change on the booster itself.
I've tried a number of different things on pfSense such as enabling/disabling automatic outbound NAT for that specific interface, changing the MTU clamping, adding forward NAT rules for ISAKAMP for udp/4500 but TNA. Can anyone offer any advice as to how I might be able to get this device to work?
At the moment i can see all traffic passing to and from the box OK, apart from when the box tries to initiate the VPN using outbound ISAKAMP tcp/4500 requests. It retries every 5 mins and I've included a paste bin link to the bit I think is failing from a TCP dump of the specific interface on pfSense. https://pastebin.com/1URs1sqw
At the moment the config is as follows:
Interface address 10.42.0.1
DHCP address of Boost box 10.42.0.2
WAN interface connected to cable modem in "modem mode"
Port mapping rule for UDP/4500 on WAN interface -> 10.42.0.2:UDP/4500
Manual outbound NAT configured - only a rule for * -> WAN address configured for the 10.42.0.0/30 subnet
Currently an additional rule for UDP/any going to WAN interfaceAny help much appreciated - I have tried all sorts of combinations and not succeeded so far - is it even possible? I'd just like to be able to allow this to connect as per the usual cable modem NAT set-up (it works when I plug directly into the cable modem with the CM in router mode.
EDIT: I can see from the packet traces that the devices gets an IP via DHCP, connects to the time service via pool.ntp.org and then downloads a config file via HTTPS (cannot tell if that is successful) however the device then attempts to initiate the VPN every time every 5 mins.
-
Hi all
New to the forum so apologies if I am asking something that is already answered - I have had a look through but as I don't necessarily know the right terminology for the issue i have I may have missed something. Thanks for any help in advance!
I have pfSense running on an old HP desktop which has a dual port Intel NIC and an onboard NIC. The intel NICs are connected as LAN and WAN and the onboard device is connected now to just a BT Cisco Signal Booster. The signal booster creates a VPN back to the mobile provider - well… it is supposed to. Unfortunately (after many tries) I have been unable to allow it to create the VPN. I believe it is failing because it does not have NAT-T enabled (that the box itself is freaking out because the packets it gets back are not what it expects?) - but I don't have any options i can change on the booster itself.
I've tried a number of different things on pfSense such as enabling/disabling automatic outbound NAT for that specific interface, changing the MTU clamping, adding forward NAT rules for ISAKAMP for udp/4500 but TNA. Can anyone offer any advice as to how I might be able to get this device to work?
At the moment i can see all traffic passing to and from the box OK, apart from when the box tries to initiate the VPN using outbound ISAKAMP tcp/4500 requests. It retries every 5 mins and I've included a paste bin link to the bit I think is failing from a TCP dump of the specific interface on pfSense. https://pastebin.com/1URs1sqw
At the moment the config is as follows:
Interface address 10.42.0.1
DHCP address of Boost box 10.42.0.2
WAN interface connected to cable modem in "modem mode"
Port mapping rule for UDP/4500 on WAN interface -> 10.42.0.2:UDP/4500
Manual outbound NAT configured - only a rule for * -> WAN address configured for the 10.42.0.0/30 subnet
Currently an additional rule for UDP/any going to WAN interfaceAny help much appreciated - I have tried all sorts of combinations and not succeeded so far - is it even possible? I'd just like to be able to allow this to connect as per the usual cable modem NAT set-up (it works when I plug directly into the cable modem with the CM in router mode.
EDIT: I can see from the packet traces that the devices gets an IP via DHCP, connects to the time service via pool.ntp.org and then downloads a config file via HTTPS (cannot tell if that is successful) however the device then attempts to initiate the VPN every time every 5 mins.
I have the same config as well, i need help too, any answer around here? much be appreciated
thank you -
You should not have to do anything to use any cell booster behind pfSense in its default configuration. If you have messed about with the default outbound NAT static port on port 500 or something, maybe you might have to undo that.
They generally initiate an OUTBOUND IPsec connection to the cell provider. Nothing should be required on the firewall. No special rules, no special port forwards, etc.
They generally require a good GPS signal and can take a LONG TIME to sync up.
The best we can try to do if it is not working is interpret the specific instructions or guidance they provided. You would need to post that.
Port mapping rule for UDP/4500 on WAN interface -> 10.42.0.2:UDP/4500
You do not need this for an outbound connection.
Manual outbound NAT configured - only a rule for * -> WAN address configured for the 10.42.0.0/30 subnet
Why manual? Automatic will capture that.
Currently an additional rule for UDP/any going to WAN interface
Zero idea what that means. Post the rule.
I realize those were posted a while ago by someone else but you stated you did the same thing.
