Configuring Transparent Mode
I want to replace a SonicWall T170 with a pfSense 1.2.3 box but I cant figure out how to configure the OPT interface in "Transparent Mode".
The SonicWall Transparent Mode settings enables the appliacen to bridge the OPT subnet onto the WAN interface. It requires valid IP addresses for all computers connected to the OPT interface, the OPT interface in Transparent mode can be use for public servers and devices with static IP addresses you want visible outside the SonicWALL security appliance protected network.
jimp Rebel Alliance Developer Netgate last edited by
Bridge OPT1 to WAN, add firewall rules to OPT1 to allow traffic out, that's all it takes.
You don't have to give it a list of IPs to use.
Also do not give OPT1 interface ip address or gateway, those are not needed when bridging OPT to WAN.
I bridged OPT1 with the WAN interface without IP or gateway, created two test firewall rules to allow all TCP/UDP and ICMP traffic in the OPT1
I can ping the WAN IP but I can't ping the WAN gateway so I cant get out to the internet from the server in the OPT1.
Here is some more information about the IP configuration
WAN Interface IP configuration:
LAN Interface IP configuration:
OPT1 Interface IP Configuration
Brdige with WAN
The Server in OPT1 has the following IP configuration:
Thank you in advance!
well the subnet mask is wrong for the server. for a /29 it should be 255.255.255.248. also what are the rules you put on OPT1?
Sorry I fat-finger the subnet in the post -it is 255.255.255.248
The rules I created on the OPT1 are:
TCP/UDP Any Source, Any port, Any Destination, Any Port
ICMP Any Source, Any port, Any Destination, Any Port
This makes no sense. The gateway is in the same subnet as the WAN IP, so if you can get to one, you should be able to get to the other. Are you sure the WAN gateway even responds to pings? And are you sure your server has a default gateway pointing to it?
Hi Dan, I sent you a private message.
I'm not interested in what the LAN hosts can do - we already know they work. When you said the WAN gateway can be pinged, I assumed you meant from the server, but the server cannot ping the WAN gateway (but can ping the WAN IP, which is why I said it doesn't make sense.) And you haven't answered my question as to your server's config.
The default gateway of the server connected to the OPT1 interface is 24.XXX.XXX.49
so to confirm: the server cannot ping outside hosts? the server cannot ping the gateway (which obviously doesn't require the gateway IP - LOL)? If you run a packet capture on the WAN interface, and try pinging the gateway IP, what (if anything) do you see? Also, I would remove the two rules and replace with a single rule that permits everything (unless you have some reason not to.)
Correct, the server cannot ping outside hosts.
I'll run the packet capture on the WAN and modify the rules later tonight and report back.
Thanks for your help so far
but can it ping the WAN gateway IP? I am reading conflicting statements about this.
I can ping the WAN IP 24.XXX.XXX.50, but not the WAN Gateway IP 24.XXX.XXX.49 from the server in OPT1
I have a total of 5 IPs from the ISP, one for the WAN and four for the server in the OPT1
if you login to the pfsense, can you ping the WAN gateway IP?
I haven't tried it, I'll do so tonight - I'm not there right now and dont have remote access yet.
I changed the OPT rule to one
Proto Source Port Destination Port Gateway Schedule
* * * * * *
I was able to ping the WAN Gateway from the pfSense console
PING 24.xxx.xxx.49 (24.xxx.xxx.49) from 24.xxx.xxx.50: 56 data bytes
64 bytes from 24.xxx.xxx.49: icmp_seq=0 ttl=64 time=1.537 ms
64 bytes from 24.xxx.xxx.49: icmp_seq=1 ttl=64 time=1.262 ms
64 bytes from 24.xxx.xxx.49: icmp_seq=2 ttl=64 time=2.456 ms
–- 24.xxx.xxx.49 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.262/1.752/2.456/0.511 ms
I ran the packet capture on the WAN interface and pinged 24.xxx.xxx.49 from the server in OPT1 and here is what I got
12 2.041353 00:50:56:94:1a:b4 Broadcast ARP Who has 24.XXX.XXX.49? Tell 24.XXX.XXX.51
13 2.782611 24.XXX.XXX.50 24.XXX.XXX.49 ICMP Echo (ping) request
14 2.783796 24.XXX.XXX.49 24.XXX.XXX.50 ICMP Echo (ping) reply
21 3.783133 24.XXX.XXX.50 24.XXX.XXX.49 ICMP Echo (ping) request
22 3.784322 24.XXX.XXX.49 24.XXX.XXX.50 ICMP Echo (ping) reply
23 4.784588 24.XXX.XXX.50 24.XXX.XXX.49 ICMP Echo (ping) request
So the server broadcast who has 24.XXX.XXX.49, the ping starts from the WAN IP and the Gateway replies back to the WAN IP instead of the Server IP
Aha. It sounds like it is doing NAT for some reason. If you go to firewall => NAT => Outbound, what do you see?
The option "Automatic outbound NAT rule generation (IPsec passthrough)" is selected.
aha, click to AON (manual) and delete the rule that then appears.
I did it and lost internet connectivity from the LAN and the OTP1 still the same.
I selected the "Automatic outbound NAT rule generation (IPsec passthrough)" back.
sorry, my bad. re-enable manual AON and tell me what rule you see.
Its ok, I appreciate you trying to help me.
Here is the only rule when manual AON is Enabled
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 192.168.1.1/24 * * * * * NO Auto created rule for LAN
okay, that is correct. can you post contents of /tmp/rules.debug?
I hope you dont mind but I emailed it to you, didn't want to post it.
Hey Dan, I just wanted to let you know that with version "2.0-BETA3" the Transparent Mode (bridge) is working. I notice one issue on the server in OPT1, if I restart it can't get out to the internet 'till I "repair" the network connection.
By repair I mean, in Windows going to Network Connections right clicking on the connection and selecting the option to repair.
Thanks for all your help
glad it is working. if this server has a static IP what you are describing is odd. be interesting to run a packet trace on the OPT1 interface after booting the server and then doing the repair.
Hi, sorry I didn't get back to you sooner, I was not able to reproduce the error to run a packet capture - I'll make sure to run capture it if it ever happens again.
Thank you again for all your help!