PfSense IAX trixbox
-
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~