PfSense IAX trixbox
-
Hi all,
Im new to pfsense and have searched a lot for an answer to my issue.
Essentially my topology looks like this:
ISP –-> myRouter ---> pfSense (static IP) --- myLAN --> trixbox (static IP)
when pfsense firewall is running my trixbox is not getting any connections at all.
nothing is logged in the firewall logs.I can dump the traffic on my ISPs router (thanks to AAISP) and I can see they are trying to talk to me :
19:33:17.244624 Tx length 65: [ses 0xb977] IP (0x0021), length 45: ThereIP.4569 > myTrixBoxIP.4569: UDP, length 15
but nothing comes through.
If I add a mad rule to allow all source, all destinations, all ports to my pfSense fw still nothing comes through.
If I disable the pfsense fw System: Advanced: Disable all packet filtering. tick
All works fine! (but no point having a firewall if your going to disable it)
This is pfSense 1.2.3 installed.
Any ideas would be greatly appreciated.
Thanks
-
You should port forward UDP/4569 to your trixbox, and add a rule allowing that (you can default that to on with a checkbox). Did you do that?
-
Hi thanks for coming back.
No I hadn't configured any port forwarding as my IP on the trixbox is configured with a static routable IP which is configured on the external VOIP provider.
I had assumed as long as UDP port 4569 was open as a fw rule to that IP, that would be all that was required?
I have now configured a port forward (still not working) although Im not sure why I'd need to manually specify that traffic coming into the WAN interface destined for
x.y.z.205:4569 would not be allowed to pass to x.y.z.205:4569
Any ideas or hints would be appreciated.
Thanks again.
-
I think I need to be de-confused here. I assumed your trixbox was behind a firewall using NAT (which is usually the case.) If not, can you more clearly describe how the plumbing fits together?
-
Hi,
Sorry didnt mean to confuse - no NAT at all on this network everything is routable static IP's.
Say (example IP's):
Gateway IP is XX.155.38.193
trixbox IP is: XX.155.38.205pf Red is: XX.155.38.206 router is plugged into this
pf Green is: XX.155.38.207 lan is plugged into thisthen
VOIP External Trunk provider knows to forward inbound calls to: XX.155.38.205
I can see the traffic leaving the ISP router to XX.155.38.205
This is a dump from there router:
19:33:17.244624 Tx length 65: [ses 0xb977] IP (0x0021), length 45: ThereIP.4569 > XX.155.38.205.4569: UDP, length 15
I have a firewall rule specified to allow:
PASS
Proto: UDP
Source: ALL
Destination: XX.155.38.205
Port: 4569I thought this should mean that all traffic coming into XX.155.38.206 (red) would be allowed unmolested to XX.155.38.207 and onto the lan
If I do a similar rule as above
PASS
Proto: TCP
Source: ALL
Destination: XX.155.38.205
Port: 22Then I have no problem at all getting a sh on the trixbox from outside the network.
All other services on this network IMAP servers, Oracle servers, wiki etc…. non have a problem with this kind of config.If I turn off the pf System: Advanced: Disable all packet filtering. tick
Then inbound calls also work fine. This evidence coupled with the ISP router dump is what makes me believe its a pf problem.
Hope this is clearer.
Again thanks for your help.
-
okay, thanks. does anything show up in the pfsense log when this is happening. if you do a packet capture on the pfsense LAN, do you see anything?
-
Hi,
No nothing in the logs.
I've just done two capture runs whilst trying to dial in. One on the wan and one the lan:
WAN Packet capture
18:44:38.362921 00:24:b2:3d:d8:f2 > 00:1a:92:29:2e:5a, ethertype ARP (0x0806), length 60: arp who-has XX.155.38.205 tell XX.155.38.193
18:44:38.362953 00:17:3f:9b:dd:25 > 00:24:b2:3d:d8:f2, ethertype ARP (0x0806), length 42: arp reply XX.155.38.205 is-at 00:17:3f:9b:dd:25
18:44:38.363038 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype ARP (0x0806), length 60: arp reply XX.155.38.205 is-at 00:1a:92:29:2e:5aLAN Packet capture
18:45:53.097058 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57558, offset 0, flags [none], proto UDP (17), length 40) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 12
18:45:54.099425 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57559, offset 0, flags [none], proto UDP (17), length 40) XX.155.38.205.4569 > externalVOIPProviderIP4569: [udp sum ok] UDP, length 12
18:45:58.096821 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype ARP (0x0806), length 60: arp who-has XX.155.38.193 tell XX.155.38.205
18:45:58.097115 00:24:b2:3d:d8:f2 > 00:1a:92:29:2e:5a, ethertype ARP (0x0806), length 60: arp reply XX.155.38.193 is-at 00:24:b2:3d:d8:f2
18:46:04.926321 00:24:b2:3d:d8:f2 > 00:1a:92:29:2e:5a, ethertype ARP (0x0806), length 60: arp who-has XX.155.38.205 tell XX.155.38.193
18:46:04.926415 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype ARP (0x0806), length 60: arp reply XX.155.38.205 is-at 00:1a:92:29:2e:5aDoes that help?
-
Is this a transparent bridge setup? I am seeing something weird. They are ARP'ing for your trixbox, and two replies are being sent back, for two different MAC addresses. ????
-
Hi,
This is the trace when pf filtering is disabled and it works:
WAN Packet capture
18:54:13.801050 00:24:b2:3d:d8:f2 > 00:17:3f:9b:dd:25, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 58, id 47889, offset 0, flags [none], proto UDP (17), length 137) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 109
18:54:13.802783 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57608, offset 0, flags [none], proto UDP (17), length 46) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 18
18:54:13.817037 00:24:b2:3d:d8:f2 > 00:17:3f:9b:dd:25, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 58, id 47890, offset 0, flags [none], proto UDP (17), length 40) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 12
18:54:14.025257 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57609, offset 0, flags [none], proto UDP (17), length 40) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 12
18:54:14.039055 00:24:b2:3d:d8:f2 > 00:17:3f:9b:dd:25, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 58, id 47891, offset 0, flags [none], proto UDP (17), length 40) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 12
18:54:15.211999 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57610, offset 0, flags [none], proto UDP (17), length 40) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 12
18:54:15.225562 00:24:b2:3d:d8:f2 > 00:17:3f:9b:dd:25, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 58, id 47892, offset 0, flags [none], proto UDP (17), length 40) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 12LAN Packet capture
18:54:53.213152 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57612, offset 0, flags [none], proto UDP (17), length 40) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 12
18:54:53.229437 00:17:3f:9c:24:fc > 00:1a:92:29:2e:5a, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 57, id 47894, offset 0, flags [none], proto UDP (17), length 40) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 12
18:54:53.229626 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57613, offset 0, flags [none], proto UDP (17), length 40) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 12
18:54:54.353898 00:17:3f:9c:24:fc > 00:1a:92:29:2e:5a, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 57, id 47895, offset 0, flags [none], proto UDP (17), length 137) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 109
18:54:54.355513 00:1a:92:29:2e:5a > 00:24:b2:3d:d8:f2, ethertype IPv4 (0x0800), length 60: (tos 0xb8, ttl 64, id 57614, offset 0, flags [none], proto UDP (17), length 46) XX.155.38.205.4569 > externalVOIPProviderIP.4569: [udp sum ok] UDP, length 18
18:54:54.369374 00:17:3f:9c:24:fc > 00:1a:92:29:2e:5a, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 57, id 47896, offset 0, flags [none], proto UDP (17), length 40) externalVOIPProviderIP.4569 > XX.155.38.205.4569: [udp sum ok] UDP, length 12How can i check the transparent bridge? sorry if this is a stupid question!
-
If you mean is the LAN interface bridged with the WAN then yes.
-
yes, that is what i meant. can you post the mac addresses of the two pfsense nics as well as the trixbox nic?
-
trixbox:
eth0 Link encap:Ethernet HWaddr 00:1A:92:29:2E:5A
pfsense:
re0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=389b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic>ether 00:17:3f:9b:dd:25re1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=389b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic>ether 00:17:3f:9c:24:fcbridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
ether 0e:67:bb:99:2b:ab</up,broadcast,running,simplex,multicast></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,promisc,simplex,multicast></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,promisc,simplex,multicast> -
this is weird. it's like the pfsense is doing some kind of proxy arp. what does your config look like?
-
I've just removed the NAT rule, which i mistakenly thought you wanted me to put in last night:
19:22:46.583484 arp who-has XX.155.38.205 tell XX.155.38.193
19:22:46.583855 arp reply XX.155.38.205 is-at 00:1a:92:29:2e:5aNow its only replying with the one MAC much more sensible.
What do you mean "config look like" firewall?
-
yeah, sorry, that was when i thought it was a NAT setup. i assume it still does not work? if so, it might be good to reboot the pfsense just to make sure everything is clean.
-
Hi,
Sorry had to go away for a few days. I've rebooted the pf box and yes - unfortunately exactly still the same problem.
-
Can you take another packet trace?
-
Thanks for all your help.
Finally got it.
In case this causes anyone else a problem:
FW –> NAT --> Outbound --> Manual Outbound NAT rule generation
And I should have.
Deleted the existing default rule.
Thanks again.
-
;D thanks i am here for the same kind a problem .Got a solution through this .
Thanks Team
K~