Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

How to allow firewall access to device with fixed IP on different subnet.

This is no doubt a simple noob question, but I may be trying to make it harder than it needs to be.

TZ470 FW with Ubiquiti switches and APs. Wired LAN and private SSID on 192.168.1.0/24. Guest SSID on 172.24.6.0/16.

Just added a postage meter that connects via WIFI on guest SSID. All the device's network checks pass and we are able to buy postage, etc.

According to Pitney-Bowes' docs, "SendPro C Auto internal base and tablet communication uses a subnet that consists of IPs from the 192.168.10.240 to 192.168.10.255 and 192.168.10.96 to 192.168.10.111 ranges."

Apparently, these devices need to periodically phone home for updates or whatever. When that happens, I get multiple log dumps to email because the logs fill up with "IP spoof dropped" alerts, primarily using 192.168.10.244.

What is the easiest way to configure the TZ470 to allow either this specific address or that entire subnet to access the internet from the X0 LAN IF to the X1 WAN IF?

Thanks, Russ

Category: Entry Level Firewalls
Reply

Answers

  • RussFRussF Newbie ✭

    @TKWITS , I read that thread before I posted my question. Here's where I'm a bit confused.

    When I set up the Ubiquity equipment and added the guest SSID, I created a vlan on the Unifi controller for that SSID as well as on the SW with a DHCP pool attached to it.

    Since the postage meter is connecting through the guest SSID, its traffic is on that vlan. Do I need to create an entirely separate SSID just for that device? Or can I just bind another vlan to X0 for that subnet?

    Russ

  • TKWITSTKWITS Community Legend ✭✭✭✭✭

    Is there really a need to create or 'bind' VLANs for the mentioned 192.168.10.x subnet? If the device works as it's supposed to but occasionally throws some packets out that are getting ID'd as a spoof is it a big deal?

  • RussFRussF Newbie ✭

    I'm sorry in advance for the length of this message, but too much to explain in just a few sentences.

    @TKWITS , you make a valid point, and that was the initial stance I was taking. Our SW is set to email its log to me at 6:00 am every day as well as whenever the log fills up on the SW. I will visually scan these logs looking for any trouble spots that may need addressing.

    Prior to the installation of the device, I usually only got the daily email and occasionally, but seldom, an overflow email. Now, 2 to 3 times a week, whenever this thing decides to phone home for whatever reason, I get dozens of emails with thousands of alerts. Quite frankly, I don't have time to go through these looking for real problems.

    And yes, the device is working properly because it was just installed, but what, exactly, are these attempted communications trying to do? Are they trying to update vital components that will eventually fail because they are out of date? No one knows. Not even Pitney Bowes. I spent three hours on line with tech support (and I use that term VERY loosely) who just kept referring me to the document I quoted above. I kept asking to escalate the call to tier II, but they insisted there was no such support available, nor was there a dedicated networking department. In frustration, I asked to be transferred to their supervisor - and they sent me to the billing department. At that point, I gave up - and they won that round. I figure that if I can just let this device do what it needs, things should be better.

    I understand (I think) the concept of vlans, but I don't have the luxury of experimenting on a live system, so I'm asking for a little guidance.

    Our private, password protected SSID is on the same subnet (192.168.1.x) as our main wired LAN, so, no problem.

    I created our guest SSID (that the device in question connects to) on a vlan with the subnet 172.24.x.x and vlan tag 10. I then attached this same vlan to the SW I/F X0 (alongside the main subnet). The packets on this subnet are tagged by the access points with V10.

    Here's where I'm confused: The device's main I/F attaches to the guest SSID (172.24.xx:V10), so it's packets carry the tag from the APs. Its "internal" components (tablet, etc) communicate through the same SSID, but on the 192.168.10.x subnet (this cannot be changed on the device). Are these packets (since they are coming from the guest SSID) being tagged with V10, even though they're on a different subnet.

    If I create another vlan on the SW with that subnet and tagged V20, how do the packets from the device get tagged (or do they need to be)? The packets are obviously making it to the SW and being rejected. This one device is trying to get through the SW to DNS's from TWO different subnets, but only one actually has a connection to the SSID.

    Does that help, or have I only made matters worse? Thanks for any help you may have.

    Russ

  • TKWITSTKWITS Community Legend ✭✭✭✭✭

    "Are these packets (since they are coming from the guest SSID) being tagged with V10, even though they're on a different subnet."

    You should be able to answer this question yourself if you are using VLANs, but the answer is yes. The log entry should provide what interface and vlan the packet arrived on, or you can run a packet capture to confirm.

    "If I create another vlan on the SW with that subnet and tagged V20, how do the packets from the device get tagged (or do they need to be)?"

    I will just say it: you don't really understand VLANs. To answer the question, the device is NOT tagging the packets, your network equipment is. Only VLAN capable devices can tag packets. I'm going to go out on a limb and say a PitneyBowes device is NOT VLAN capable.

    This device clearly is annoying you, so let's cut to the chase. Do you know the what the device expects as a default gateway for the 192.168.10.x network? If so you can ARP that address to the X0:V10 interface, and provide a route statement for the 192.168.10.x utilizing the same interface (this was all provided to you in my first reply). Once that is done the device should be able to access the internet and quiet your log files.

    Read up on ARP, IP Subnetting, Broadcast Domains, and VLANs.

  • RussFRussF Newbie ✭

    "You should be able to answer this question yourself if you are using VLANs, but the answer is yes."

    Actually, the log entry is

    "Alert - 192.168.10.244, 56880, X0 - 8.8.8.8, 853, X1 - dns.google - tcp - IP spoof dropped" (thousands of them!)

    The destinations seem to alternate between google's dns and our own ISP's dns (which I assume the device is getting from DHCP when it connects on 172.24.x.x on our guest SSID.

    "I will just say it: you don't really understand VLANs. To answer the question, the device is NOT tagging the packets, your network equipment is...."

    I never once said that. I said, "The packets on this subnet are tagged by the access points with V10." and, "...how do the packets from the device get tagged..." I KNOW that the device doesn't tag the packets. I was asking if they need to be. They seem to be getting to the SW, so perhaps not - that is what I don't know.

    "Do you know the what the device expects as a default gateway for the 192.168.10.x network?"

    I have no idea. This device (a postage meter) has a wifi connection right now on our guest SSID with an IP address of 172.24.12.47. The gateway for that subnet is 172.24.0.1 - which I have set up on VLAN 10 and is given out via DHCP to devices on the guest SSID.

    However, according to Pitney Bowes, "INTERNAL" to the unit, there is a "base" and a "tablet" on subnet 192.168.10.x that cannot be changed and supposedly is used for internal communication within the device. I don't have access to those settings. I don't know what the default gateway is set as, but the packets, according to my syslog entries, are destined for a MAC address on the SW.

    So, there is a device internal to the postage meter on one subnet, sending packets through the meter's wifi connection on a DIFFERENT subnet and addressed to an internet DNS via the SW's MAC address.

    There is nothing in the logs to indicate anything different. No, I am not a networking expert. No, I don't understand how the scenario I've described could work. If I did, I wouldn't be here asking for advice. I've never had to "ARP" anything - going to go read up on that now...

    Russ

  • TKWITSTKWITS Community Legend ✭✭✭✭✭

    If the request is hitting the X0 interface as the log says ("Alert - 192.168.10.244, 56880, X0 - 8.8.8.8, 853, X1 - dns.google - tcp - IP spoof dropped") than the ARP'd address should be done on that interface. I don't know how it would hit just X0 and not X0:V10 if its really connected to the guest SSID; unless of course none of your guest traffic is actually being VLANd.

    Run packet captures on both X0 and X0:V10 looking for traffic from the 192.168.10.244 address. That will definitively tell you which interface that traffic is hitting.


  • RussFRussF Newbie ✭

    @TKWITS , I think now you're beginning to see the source of my confusion and frustration. Can you help me understand how this is happening?

    From the Unifi controller, you see the subnet that the main I/F of the postage meter (PM) is on (note the MAC):

    From the syslog, again, note the src & dst MACs:

    Two shots from the SW I/F edit screens:

    From this, it should be clear that the PM on 172.24.12.47 is transmitting packets from 192.168.10.244 over VLAN 10 and they are hitting the X0:V10 MAC address. Can I assume that it is using 172.10.0.1 as the default gateway? If so, that gateway is already allowing traffic to pass.

    I have been in meetings all morning, but I will look into setting up the packet monitor and see if I can glean any more data. I really appreciate your help.

    Russ

  • TKWITSTKWITS Community Legend ✭✭✭✭✭

    "From this, it should be clear that the PM on 172.24.12.47 is transmitting packets from 192.168.10.244 over VLAN 10 and they are hitting the X0:V10 MAC address."

    The MAC address of VLAN interfaces is shared from the parent interface, so thats not an accurate statement.

    "Can I assume that it is using 172.10.0.1 as the default gateway? If so, that gateway is already allowing traffic to pass."

    You can't assume in networking / computers. They only do the things they are told to.

    Have you read this?


Sign In or Register to comment.