I have Fusion Hub running at AWS with:
Interface WAN IP Address: 10.1.0.8 (This IP has a public Elastic IP assigned)
LAN IP Address: 10.1.0.13
My Max Transit is connected to the AWS public IP, and Internet traffic from clients connected to the MT is working fine, however I can’t see any other resources on the 10.1.0.0/24 subnet. I can ping both 10.1.0.8 and 10.1.0.13, but none of the other computers on that subnet.
I have also “stopped” the source/destination check on the fusionhub instance.
The strange thing is that this was working fine, until I accidentally let my PrimeCare license expire, which disabled my Speed Fusion connection. I paid for the new subscription and rebooted the MT and it came back up and connected, I also updated firmware on both devices, but now I can’t see other instances at AWS.
I also noticed I don’t have the “SpeedFusion Peers Access Internal Network” section anymore. Did I lose this as part of the firmware upgrade? Could that be my issue?
Your LAN and WAN ip spaces are the same /24?.. 10.1.0.0/24
That isn’t usually valid… they should be two different subnets, or you just shouldn’t use the LAN.
I know you said it worked before, but sometime that was “wow, that was a miracle, and the miracle is gone” It shouldn’t have worked, and today, it doesn’t.
How do you have a route to 10.1.0.0/24 on the Max transit?. Is it via an outbound policy or OSPF via the SF tunnel?..
There are too many variables at play. kill the lan part…
Next up, use routing for finding the subnet. So on the FusionHub → Network → OSPF & RIPv2
click on the 0.0.0.0 area and add the WAN interface into that area.
that /24 should now show up in all of the Status - OSPF messages and in speed Fusion status page.
Now your path to the subnet is stable. If that doesn’t give results, then we should get out the packet captures and verify does #1 the traffic leave the WAN interface, and is it NAT translated. #2 do the packets come back from the other server to the WAN IP.
Can you ping the other devices on 10.1.0.0/24 from the WAN IP? and vice versa? (system-> Ping)
Good, I like simple. The problem is that the Outbound Policy should have routed the packets the same way, I just prefer to use routing over magic policies where appropriate.
Next question, do you need to have any traffic originated from the AWS subnet → the Max transit?..
I can’t think of a use case right off for AWS → MAX but it could be useful, and I did add a route at AWS to the FH, not sure with nic it’s on (LAN OR WAN). I still have both, BTW.
You can port forward… but for real routing you would turn off the “NAT the PEPlink VPN” and then you need to have routes set up in the AWS route table. There can be interesting side effects with linux and windows servers, and the FusionHUB. None of them like ICMP redirects,
You want a non-NAT fusionhub WAN to only talk to routers. No hosts on that network, I learned the hard way. Hosts only want 1 default router or you have to configure static routes on each one individually.
Hummm… Okay, I set the LAN interface to Connection Method: None, and removed the nic from the AWS Fusion Hub instance. I probably need to reboot, but I haven’t yet.
When I turn off “Apply NAT on Remote peers’ outgoing Internet traffic” on WAN for the AWS Fusion Hub instance, the constant ping I have running from a Max Transit client stops. With it on it works. In either case, the ping I have running from another instance at AWS to a Max client does not work.
I have a route setup at AWS for the subnet the Fusion Hub instance is on for 192.168.1.0/24, pointing to the WAN NIC.
…and I can ping the client behind the Max Transit from the ping tool in the Fusion Hub instance!
Not sure what to try next?
Thanks again for all of your help, if I can get this working both directions it would be awesome!!!
I tried to DM but it won’t let me. (you might want to move the debugging part off the forum).
We can start small… can you add a static route on one server to the WAN IP… and see if you can then ping both ways from that IP?.
If that doesn’t work then can you tcpdump from that one server?.. we need to see which way the packets are flowing.
Now I haven’t done this in AWS, but I did in a different network environment. (and I seem to be locked out of my AWS at the moment).
Ultimately you want to bring up a new network… 10.0.2.0/24 Move the WAN interface to that network, map the ELB to that new IP. and add the static route to the route table.
It worked with a static route, and therefore the final design where you move the FH to a separate network is supported by AWS’s documentation:
Routing for a middlebox appliance
“The appliance must be configured in a separate subnet to the source or destination traffic.”
They don’t detail “why” you have to do it this way, but it comes down to how hosts and routers are different… In todays systems hosts expect only one gateway via the default route, and any change to that is rejected by default configurations without individual static routes on each sysstem. Therefore routing connections should happen behind the AWS route fabric. This is true of any modern network… hosts all connect to a single upstream router, and then the routers can talk among themselves with OSFP, BGP etc.
