Simple Router

[gc-ssmic]

I am missing something simple here. I have looked everywhere but can't seem to find an answer.

We have network setup for testing. It is separated from main network with a router. We hadn't used it in sometime and now it isn't working. I am not sure if anything was changed.

The configuration in rc.conf is as follows

hostname="ALT-ROUTER"
sshd_enable="YES"
dumpdev="AUTO"
ifconfig_xn0="inet 192.168.4.1 netmask 255.255.255.0"
ifconfig_xn1="inet 192.168.3.3 netmask 255.255.255.240"
defaultrouter="192.168.3.1"
ssh_enable="YES"
gateway_enable="YES"
static_routes="net1"
route_net1="-net 192.168.3.0/28 192.168.3.3"
firewall_enable="NO"


From the FreeBSD machine I can ping everything including 8.8.8.8
From the PC I can ping 192.168.4.1 and 192.168.3.3 but nothing else.
I have read and I keep getting the samething - I just need to add gateway_enable="YES" to rc.conf and it should work.

Appreciate any help

 

[SirDice]

static_routes="net1"
route_net1="-net 192.168.3.0/28 192.168.3.3"

Don't need this static route on the FreeBSD host, the 192.168.3.0/28 range is a "directly connected" network on xn1.

You do need a static route on the firewall. It has to know it can find the 192.168.4.0/24 network behind 192.168.3.3. The pings from PC1 to the firewall actually arrive there but the response gets routed incorrectly. So your pings are going to time-out.

 

[gc-ssmic]

Don't need this static route on the FreeBSD host, the 192.168.3.0/28 range is a "directly connected" network on xn1.

You do need a static route on the firewall. It has to know it can find the 192.168.4.0/24 network behind 192.168.3.3. The pings from PC1 to the firewall actually arrive there but the response gets routed incorrectly. So your pings are going to time-out.

Thanks for the reply. I added the static route to see if that would fix the problem. I do have a route on the firewall. I should be able to ping 192.168.3.2 though as it is directly connected to the router and doesn't go through the fw.

 

[gc-ssmic]

Thanks for the reply. I added the static route to see if that would fix the problem. I do have a route on the firewall. I should be able to ping 192.168.3.2 though as it is directly connected to the router and doesn't go through the fw.

I finally figured it out. There was an issue with the NAT on the firewall.

Thanks for the help.

 

[SirDice]

The switch needs to have that same static route. It'll receive a ICMP echo request from 192.168.4.12 but doesn't know where to send the reply to. Its default gateway is probably set to 192.168.3.1, so the response gets send to that.

There was an issue with the NAT on the firewall.

That would be weird. Traffic from PC1 to the switch never passes the firewall, or at least it never should, unless your routing is messed up.

Just follow the packets. A ping from PC (192.168.4.12) to the switch (192.168.3.2), and assuming PC only has a default gateway; 192.168.4.1.

• destination address is outside the directly connected 192.168.4.0/24 so has be sent to the default gateway
• packet arrives on FreeBSD host on xn0
• routing knows 192.168.3.2 is connected on xn1 and does an ARP request, then sends the packet to 192.168.3.2.
• switch receives echo request from 192.168.4.12, and sends the echo response back.
• switch doesn't know where 192.168.4.12 is, so sends it to its gateway; 192.168.3.1 (guessing here).
• firewall on 192.168.3.1 receives echo reply from 192.168.3.2 with destination address 192.168.4.12.
• firewall has no state for this return traffic (it never saw the echo request) and simply drops it.

The switch should not send the return packet to the default gateway. Therefor a static route needs to be added here too, so it knows to send the return traffic for 192.168.4.12/24 back to 192.168.3.3 instead of 192.168.3.1.

What a lot of people tend to do, is to enable NAT on the FreeBSD host (not the Firewall host) because they can't figure out how get routing to work properly. Then the whole 192.168.4.0/24 network is "hidden" behind the 192.168.3.3 address of xn1. NAT should only be used as a last resort in my opinion, if, for example, you have no control over the configuration of the Firewall host and/or switch.